NOT 
MEASUREMENT 
SENSITIVE 


MIL-STD-188-141B 
1 MARCH 1999 


SUPERSEDING 
MIL-STD-188-141A 
15 SEPTEMBER 1988 


DEPARTMENT OF DEFENSE 
INTERFACE STANDARD 


INTEROPERABILITY AND PERFORMANCE STANDARDS 
FOR MEDIUM AND HIGH FREQUENCY 
RADIO SYSTEMS 


AMSC N/A AREA TCSS 
DISTRIBUTION STATEMENT: : Approved for public release;distribution unlimited. 


MIL-STD-188-141B 


FOREWORD 


1. This standard is approved for use by all Departments and Agencies of the Department of 
Defense (DoD). 


2. In accordance with DoD Instruction 4630.8, it is DoD policy that all forces for joint and 
combined operations be supported through compatible, interoperable, and integrated Command, 
Control, Communications, and Intelligence (C3I) systems. Furthermore, all C3I systems 
developed for use by U.S. forces are considered to be for joint use. The director of the Defense 
Information Systems Agency (DISA) serves as DoD's single point of contact for developing 
information technology standards to achieve interoperability and compatibility. All C3I systems 
and equipment shall conform to technical and procedural standards for interface, interoperability, 
and compatibility, as recommended by DISA. 


3. MIL-STDs in the 188 series (MIL-STD-188-XXX) address telecommunication design 
parameters based on proven technologies. These MIL-STDs are to be used in all new DoD 
systems and equipment, or major upgrades thereto, to ensure interoperability. The MIL-STD-188 
series is subdivided into a MIL-STD-188-100 series, covering common standards for tactical and 
long-haul communications; a MIL-STD-188-200 series, covering standards for tactical 
communications only; and a MIL-STD-300 series, covering standards for long-haul 
communications only. Emphasis is being placed on the development of common standards for 
tactical and long-haul communications (the MIL-STD-188-100 series). The MIL-STD-188 series 
may be based on, or make reference to, Joint Technical Architecture, American National 
Standards Institute (ANSI) standards, International Telecommunications Union - 
Telecommunication Standardization Sector (ITU-T) recommendations, North Atlantic Treaty 
Organization (NATO) Standardization Agreements (STANAG), and other standards wherever 
applicable. 


4. This document contains technical standards and design objectives for medium- and 
high-frequency radio systems. Included are: (1) the basic radio parameters to support both 
conventional and adaptive radio communications; and (2) technical parameters for automatic link 
establishment (ALE), linking protection, and other advanced adaptive features and functions. 


5. The technical parameters in certain identified paragraphs have not (as of the date of 
publication) been verified by testing or implementation. These parameters have, however, been 
subjected to rigorous simulation and computer modeling. The DoD working group and the 
Technical Advisory Committee (TAC) are confident that these features, functions, and 
parameters are technically valid. The un-tested portion of the technology are marked (NT) 
following the title of each paragraph containing un-tested material. 


6. Users of this MIL-STD should note that there is no proprietary or otherwise restricted use 
material in this document. This document is for unrestricted DoD, federal, and industry use. 


MIL-STD-188-141B 


TABLE OF CONTENTS 


PARAGRAPH PAGE 
Vs SCOPE «sic size Sense ces a deta scan ass des hrc Cas aps in Sed scales testa aha bates Wape vende ss daa nian aa ie ae anipeata pete edeh 1 
Meth (SCOP Gye setties eu cca ti neces aac eae eas aes GN ca eae ia aca a eae atte 1 
ADs Bia UA. 5 2 ot lal ul v yas cicada cracaaiopcca posse nce ssa teans apne anu amis Meseato nave daebaimiees 1 
15 3 App ne ans INET aoe Soe ascent exe tec age ea tse mateo ge ie a ea 1 
2¢ APPLICABLE DOCUMEB INES cst sscceudecassains eaeitaaieuaisaecheuem massa ane aeGum wnereenais 1 
Dede ASTUTE AL 86 eats das be oko lec wba da evsnv aise Daa eas pega was Lag aaig ta ABR Da Caan a aa oa ages aac anne aed ats 1 
D2” COV crm Git COC UMICINS jit iat ess laisse Sus Neca tanta tena aIRs ae adalat 1 
2.2.1 Specifications, standards, and handbooks. ...........cceccceccceeseeeceeseeceeceeeeeeeceeseecseeseeensees 1 
2.2.2 Other Government documents, drawings, and publications. ..0.......ceeeeseeeseeeteeeeeeeeees 2 

2.3 Non- Goverment publications ss, syisssissccivestesndesascagy steers aaccas ante anja decee dessa tiaatcvehtedeatoe 2 
DAL OUCIGT OR PRECEUSIC ecco iA Sate etal es Sasha cet i cadaec bales ara ca Sata el eae shit es hata, et 3 
BEE INT BION Ss sini Coster ieee catia yy iaanat nila iincesly Nuts teeta yelepa imitans Wheys ram aay cel eNieeuse 3 
reel © ASTI e222) calla thc Sted Nn ai asc sg tl te io Stal a cade tase macho el cea en ae a e Nate hth aces 3 
32. ABBE ViatiONs ANG, ACLOM YTS... cana resiedades sg ouatecvstclesct catuucasn siacssteacen suavemetearescucteetucnenyaatee tee 4 
A ATEN RA Ey RIOR EIEN IE SS. sts cact rt titsaa wigs ma ie dounalere ewes entuasaseeece be nsusanigec Gone Nore egues 5 
PM: AG MIC TAL 5. sys Fashezell veg vp cos aaiees dtu sch elu Sepa as os ana ola haa ona Ga nwa 5 
412). BQUipimient Parameters. sy cscs ceils tiv tapeadean cuba ete yecessincanta veep ayeeienes anes Mededs 6 

A: 1.2. BasicHiE TadiG Parameters ie ciiel isp sce easti ada omiatiea is tances eet ene 6 

ADs EQUIDIIE MLO PER ALTON: ITO UG: ccs ose fees sechocze sven duces aecuccteseseeeae ka yeuae Nasco sapos ace eetestosteanevSeaehaben 7 
AD. 1 Baseline mid 6 pe gsccsetegs terecte tvs tasgan Weeene tena Rasta este Gece ese 7 

dh DD PAISHLO Tal ODETALMOTN 25. fara aes ost cree ae aca tanaseyreattul We cedsutes testis secu acetal auntie Aaa 8 

Dh 2D: PEE MOOG sad essives ists hvsncat an but ea-eeedus eave baws wba ace d aa snsnea yasbus eusree qhonds pxkiba saad ataascnd alshearesavasaaa 8 
AD As PATE P ANTE) AOE fc caat' sarnecnas gh shee seoicosuie casa Seh nsateeatuceesocseeneteens omesene secant bane teamanbonenanses 8 
42.5 Linking protection (LP): ais.tes svete ssh adcarieae iaeteststes Wada at Ae eae A 8 

AsS- Mtr Pace Parameters. ica, ccsniuiowiavescayinessdadtdncilu ced coe udusseetundeuasadena tens saple teen a Sueae Aen eie 9 
4.3.1 Electrical characteristics of digital interfaces..........cccecccesceseeeesceeseceseceeeeeseecseenteeeees 9 
4.3.2 Electrical characteristics of analog interfaces. .........ececcecsscceseceseceeeceeseeceseceeeeeeeenseenes 9 
4.3.3 Modulation and data signaling rates. 0.0... eccecscecseceneceeeeeeeceescecaecnseeeeaeenseecueeneenaees 9 

4.4 NATO and Quadripartite interoperability requirements. .............ccecccesceeeeeeeceeeeeeeceteeeeeees 9 
4.4.1 Single-channel communications SYSteMS. ..........ccccccceceseceseeeeseeesceceseceeeeeeeesseecsaeenteeesaes 9 
4.4.2 Maritime air COMMUNICATIONS SYSTEMS. .........eeececsceesteceteceeeeeeeceeseecseceeeeeeeeeseecsseenteeesaes 9 
4.4.3 High-performance HF data MOdeMS; v5.0 c3s..<0e.beseiseedechesscssvncclaladensetstedihesdivevicdaseendendas 10 

Th Ae MVS VIS po tie ada a Scat Agel cnn wate ei oO a as Tae aie 10 

AD <A aptly © COMMUNICA ONS 4 seccrsiei st aise dott eaiatesgs thn ave sa toa haus sepa Peta vaieetiea sda eateicegient 10 
AO TAK TV PE OLCC CO acne. bs aesraste ciated ce tecsan hc edude a sSascedtec ecu su suntv bdades we caede ovteeas causaan ghadene 10 
4.7 TAB data JNK proto COs ccs. ieativadacty haeiavasitacteaateoeadevalecahs alee Maes eae a 11 
A-8 Nei WOLKING MINCTONS usa. ecih at uate aun oa ula shea cet cee say hare la oe ea at Maratea dy 11 
4.8.1, Indirect callitie and Pebayin ge s,.ccsscsissasaclocash iad derasenitaethsnaatads tates tiaeelameaband series dec atone 11 
AVS 2 > INCEWONK: Maia CHIGIIL. “>, sa cctcaizendeet ava aaatestareahnastaannietsayuateeauateaetatantaa see aneneadacemanauneattane 11 

4.9 Application protocols for HF radio networks. 02.0.0... cecceescesseceseeeeeeeeseeceeeceseeeeeeenseeeaeenes 11 


il 


MIL-STD-188-141B 


TABLE OF CONTENTS 


(continued) 

PARAGRAPH PAGE 
5. DETAILED REQUIREMEN TB aig sieceres hesisises ticaze Maavecsectad tei casnneres Mandeicateincshadeuceia laden tis 13 
Sl MS CHSLANS esse aussduewiusuiset avant eeiyetcaeieeveceeantiaee aves tlw beet copa tenaaae ey hese nbn ee teantweinnOays 13 
Diol Tine Ot OM oar sect tease asyciggia aida asad dolothe eSie Meted ad ais nad bs ae opaad alae anatase 13 
Doha 2e Slot ANC NOISE Pe lAtIOM SHI Svc. cydauscan'ss adaars evowesecs cei eeoduasantaeduseate cand omdade avteuaneasdacesnt 13 
5.2 Common equipment Characteristics. ..........cccccsccesceeceesseeeeceeeceeeeeeseecaeceeeeeeeeeseecseenteeeaees 14 
Se). Displayed Pequeney exacts fet career tac sitisa uriantaliientsunte a tiauk aunts oa te rlan mi ts 14 

J. 2,2) PYCQUCTIOCY COVETAGE a: 121dacst<texnensastacss stbesancabandagsuoasedads letannesbanndanats deideaa ban dadigoueveadsiatounlae 14 
Diao MICQUCIIC V-ACCUIACY,. A turscaccosetaracdashouch tudes tees dececaaseeatav a Gaatoenseegeenta nee audatees 14 
D2 A Phase Stability sk acitaseamactacuenic aan dante whine eas aes ls 14 
Dis Zao? (PNAS TOTS 25. ehuiess dys coa cal de ev lutd dos ubs saat nad eux cbicaasdun caewslayaeds iaehaeseaiatesdutaenceecene its 14 
Oye Eo AIM WRUNG 92098 oe teagas tec nalaorciue tf niu aecestecbaled exe ake eco eaanco nad eeaaed neta sais eles atime aedeaten wes 17 
ets VET AIC MANTIS TES PON SES peaches ius olor a'cy aeecessya cede tat oatsesrows datos vans areata es ouaress Reese memes lasaots 17 
528 ADSOMI SACLAY cavcsschtharspistiety a ca wages Bactaad naitbaieee ch mnedaettactiand baediie eae aiden 19 
Di ot RAN Sitter. Char aCteniStiCs xc5.c leas iwhans aks iassaneute a tuaduapbsundianeaut nude Cusieatatay tan tuicaarstiutameaat uses 19 
Sid. NOISES ANGI TORN p22) acha ce) Saks cchaaas eins saeneadsaeiacehdnesnchsaeideasdard a paenees ease odes 19 
Ds 2 SPCC AL PORN Ys sacsecstcicuin teyeuceaesaans asa Ncens vig tee ndeeeeoue pangs eee cenatuaie co mdawwaraah anes GaaNeonasany 21 
5.3.3 (Carrier SUPPRESSION 5 x4 nasi Hara dowottewe shit tee tence tekeia Said dasaalse be Sait eheee aso aike lens 23 
534° Anitomatic level control (ALC) aiken ahead BA 23 
5.3.).2tack and release time Celays.acus.bsisreea ti aiales natn baasattiestaicremanaaliaa Rares 25 
5.3.6 Signal input interface characteristics. ...........ccssccssccsscsssccesscsesnssesscsscessccssssssnsenscessacenes 2 
5.3.7 Transmitter output load impedance... ecceccceecceesceesseceseceeeceeeeceeceeeeeeeesseeesseeneenaes 25 
Dia RECRIVEL CharaCtcristiCs: slau ta shi canteens thas uthchetet reds Ae yucy Mam se aa ns teatet coca tetas! oF 
5:41 RECEIVEr TH CHAPAClCrIStiGS +, x24, x1 sexes easantazesaggadnes tatund estate erabiers aatandastaorcedestanse yeas tates ees 2d 
5.4.2 Receiver distortion and internally generated spurious OUtpULS. 0.0.0... eee eceerteeeteeees 28 
5.4.3 Automatic gain control (AGC) characteristic. 00... eee ccccceseceseeeseecseceeeeeeeeeeseeesaeenes 29 
DAA CK ECEIVED Gantt y <a :isconwssess caue lav oyuasideu oy daeg tic ake tah uveaieasran ie caiuycceiaab ates 29 
DA) Miter lace c HarAaCleniStiGs: vila, scaseassssltd asseaediusistandonuy ibanduelge sausedant td meaavdes erode eamundonniede 29 
PN asec pce See seeacoe Slits cay codecs an a Castor ae casted vn sh Senses oo mea eck es oe 30 
5.51) Basic LE (2 Gi) jcgcia vn ecstcece ss seiciges get ane ea anima eba ete pines decors earch ee aac taad 30 
it Pate | a Bingen erento ers Eee er a era ree mrt tees Peon gore REO ree en PR rare error 30 
D> MDs pct acatinssacaranva puoitiadanusedaas sa igagaedunaysaviy isdasnssedo ewes aelan donee calaancea tsa ee lane MY 30 
5.7 ALE control functions (orderwire fUNCtIONS)......... eee eceeseceteceseceeeeeseceeeeeeeeeseeeuecneensees 30 
5.8 > Networking TUNG tons: jee cs exiirce veces doswsins ate chabuereala mio. Senidint accsent feshea Ae tiba aes 30 
5:9 Network management, o..csaiycataiantaneacuesatukas ey cadaciina i ucatiniawnans 30 
3 OnE Application MetACe ges pieisuac nape elseiea stk a lescoder tae ae dm aed ae eee 30 
Del AAT POCO 0 Fades aaateti tesla’ accueavaddeasl wontedua mace ieatuere ses ece intone Net reusedeeene Ral 
5.12 -Anti-jam Capability - ssiedecsisdecti ss tataays satecteateciguesiogeee dead anatec atte Wg he ee aaa 31 
5.13 Automatic repeat request (ARQ) protocol. 0.0... ceccccsccessecetecesecsseecseecesecseeeeeseecssecnteesaees 31 


ill 


MIL-STD-188-141B 


TABLE OF CONTENTS 


(continued) 
PARAGRAPH PAGE 
Mi. INOS oars tees ack ciel coaa lev ode teole Oba cda la Vek ics detuleawiea te hate cbes see se odes caving Meshell eoteus das lebialtavetepeateeets Gas 31 
Gil: Mnpem eG WSC: ai, 05 ete te egestas erat ten cay ay cog Lettie a te at ee te 31 
Gi2, iter ae TOMA TA TEIN ic cassscaas ad aa hai aalas ties ence pa alse vees aa maesinn eavau tans Meaedoactakan on gneawietdee wae wise 31 
6.5 ISSUC OT DODDS seca cacesse secede ol ioaiidet cides ses utes yt aeans ets eee 34 
6.4 Subject term (key word) listing 4.2.i.c9s) tects theater ausdoche teadvestecteteegnieasetetetaadete aes 34 
6.5 International standardization agreeMents........... cee eeeceeseeesceceseceseceeeeeeseeceeeeeeceseecsaeeneensees 35 
6.6 Electromagnetic compatibility (EMC) requirements. ...........cececcceesceceteceseeeeeeesseecsaeenteeeseee 35 
TABLES 
TABIGE. Ta Rela yin alteriative MOLES... cs. cient wie Goieieinly cai eetcgeiaan he Sa cee aane Steet a daca una ate 13 
PABISE ATi, Bear Wa tis 25a x.y isaastes ena oss losses coessg aya tas wu earagdaiad va ecetes bea wanna nasa nsnean daaevardeseaedee 17 
TABLE III. Out-of-band power spectral density limits for radio transmitters. ....... ee eee eal 
TABLE IV. Interaction matrix: General features... ee cesecsceeseeeeeeeeceseceeceseceaecseeeaeeeneeereeaeenaes 32 
FIGURES 

FIGURE 1. Physical layer with transceiver and modem elements. ...........eceecceeeceeceseceeenseeneeeneees 7 
FIGURE 2. Radio subsystems interface points. ..............scccsccsserssssccssccesscssccssecsescesacesscssanseeassnates 9 
FIGURE 3 Relavine aitertatives ti css. daauiy es icevass date eanester nyt iasiad tatu ean ladareateseameae inh 12 
FIGURE 4. Phase noise limit mask for fixed site and transportable long-haul radio transmitters. 15 
FIGURE 5. Phase noise limit mask for tactical radio transmitters. 0.0... cece eseeeeeeeeeeeeeeeeeeeeaee 16 
FIGURE 6. Overall channel response for single-channel or dual-channel equipment. ................ 18 
FIGURE 7. Overall channel characteristics (four-channel equipment). ...........c ec ceeeeeeeeeteeeteees 20 
FIGURE 8. Out-of-band power spectral density for HF transmitters, 0.0.0... ccceecesseeeteeereeeteees 22 
FIGURE 9. Discrete spurious emissions limit for HF transmitters. 00.0.0... cece eeeeeeeseeeeeeeeeeeeees 24 

FIGURE 10. Output power vs. VSWR for transmitters with broadband output impedance 
TISUMOTKIS js kee iota ei Aerated asus gG RCA aes beast ek nepbu titan Da ie Riya eesen rata 26 

APPENDICES 

Appendix A. Automatic Link Establishment System ...0...0...ccceeceecceeeceeceseereeeseeeeceseceaecneeeneeseeees 36 
Appendix B-: lems PEOtGenOn aia sins aette tthe ates tate? else anaes ek Basa ooo taal canis la pe 
Appendix C. Third Generation HF Link Automation... ceceecceseceseeeecesecneeeeeeeeeeeeeeenaeeneeeaee 264 
Appendix: D; FIP Radio Networking a.c2; cAts.ascacecseaauseustundeccsesstauass eaveinsesaetearccaseesauss wees 440 
Appendix E. Application Protocols for HF Radio Networks ..0.......:ceceeceseeeteeneeeeeeeeeeeeeeseenseeaee 488 
Appendix F. Anti-jam and Anti-interference Techniques ............ccecesscesseeeeeeeeeeeeecesecnseeaeeneeeaee 499 
AppendieG...EF: Data Cink Rrotocol sjss.ctedsaccaveiadictuuasa corned, idea aiesnisteks adv ene mawebaee oynalsetenartes 509 
Appendix H. Management Information Base for Automated HF Radio Networks................0 512 


iV 


MIL-STD-188-141B 


1. SCOPE. 
1.1 Scope. 


The purpose of this document is to establish technical performance and interface parameters in 
the form of firm requirements and optional design objectives (DO) that are considered necessary 
to ensure interoperability and interface of new long-haul and tactical radio systems in the 
medium frequency (MF) band and in the high frequency (HF) band. It is also the purpose of this 
document to establish a level of performance for new radio equipment as is considered necessary 
to satisfy the requirements of the majority of users. These technical parameters, therefore, 
represent a minimum set of interoperability, interface, and performance standards. The technical 
parameters of this document may be exceeded in order to satisfy certain specific requirements, 
provided that interoperability is maintained. That is, the capability to incorporate features such 
as additional standard and nonstandard interfaces is not precluded. 


1.2 Applicability. 
This standard is approved for use within the Department of Defense (DoD) in the design and 


development of new MF and HF radio systems. It is not intended that existing equipment and 
systems be immediately converted to comply with the provisions of this standard. New 
equipment and systems, and those undergoing major modification or rehabilitation, should 
conform to this standard. If deviation from this standard is required, the user should contact the 
lead standardization activity for waiver procedures. 


1.3 Application guidance. 

The terms “system standard” and “design objective” are defined in FED-STD-1037. In this 
document, the word “shall” identifies firm requirements. The word “should” identifies design 
objectives that are desirable but not mandatory. 


2. APPLICABLE DOCUMENTS. 


2.1 General. 

The documents listed in this section are specified in sections 3, 4, and 5 of this standard. This 
section does not include documents cited in other sections of this standard, those recommended 
for additional information, or those used as examples. While every effort has been made to 
ensure the completeness of this list, document users are cautioned that they must meet all 
specified requirements documents cited in sections 3, 4, and 5 of this standard, whether or not 
they are listed. 


2.2 Government documents. 


2.2.1 Specifications, standards, and handbooks. 

The following specifications, standards, and handbooks form a part of this document to the 
extent specified herein. Unless otherwise specified, the issues of these documents are those 
listed in the issue of the Department of Defense Index of Specifications and Standards (DODISS) 
and supplement thereto cited in the solicitation (see paragraph 6.3). 
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STANDARDS 
FEDERAL 
FED-STD-1037 Telecommunications: Glossary of 
Telecommunications Terms 
DEPARTMENT OF DEFENSE 
MIL-STD-188-110 Interoperability and Performance Standards for HF 
Data Modems 


MIL-STD-188-114 Electrical Characteristics of Digital Interface 
Circuits 


MIL-STD-188-148 (S) Interoperability Standard for Anti-Jam (AJ) 
Communications in the High Frequency Band 
(2-30 MHz) (U) 


(Unless otherwise indicated, copies of the above specifications, standards, and handbooks are 
available from the Standardization Document Order Desk, 700 Robbins Ave. Building 4D, 
Philadelphia, PA 19111-5094.) 


2.2.2 Other Government documents, drawings, and publications. 

The following other Government documents, drawings, and publications form a part of this 
document to the extent specified herein. Unless otherwise specified, the issues are those cited in 
the solicitation. 


U.S. DEPARTMENT OF COMMERCE 
National Telecommunications and Information Administration (NTIA) 


NTIA Manual of Regulations and Procedures for Federal Radio Frequency 
Management 


(Applications for copies should be addressed to the U.S. Department of Commerce, NTIA, Room 
4890, 14th and Constitution Ave. N.W., Washington, DC 20230.) 


2.3 Non-Government publications. 

The following documents form a part of this document to the extent specified herein. Unless 
otherwise specified, the issues of the documents which have been adopted by DoD are those 
listed in the issues of the DODISS cited in the solicitation. Unless otherwise specified, the issues 
of the documents not listed in the DODISS are the issues of the documents cited in the 
solicitation (see paragraph 6.3). 
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INTERNATIONAL STANDARDIZATION DOCUMENTS 
North Atlantic Treaty Organization (NATO) Standardization Agreements 


(STANAGs) 
STANAG 4203 Technical Standards for Single Channel HF 
Radio Equipment 
STANAG 5035 Introduction of an Improved System for Maritime 


Air Communications on HF, LF, and UHF 


(Applications for copies should be addressed to: Standardization Document Order Desk, 700 
Robbins Ave. Building 4D, Philadelphia, PA 19111-5094.) 


Quadripartite Standardization Agreements (QSTAGs) 


QSTAG 733 Technical Standards for Single Channel High 
Frequency Radio Equipment 


(Application for copies should be addressed to: Standardization Document Order Desk, 700 
Robbins Ave. Building 4D, Philadelphia, PA 19111-5094.) 


International Telecommunications Union (ITU), Radio Regulations 


CCIR Recommendations 455-2. Improved Transmission System for 
HF Radiotelephone Circuits 


(Application for copies should be addressed to the General Secretariat, International 
Telecommunications Union, Place des Nations, CH-1211 Geneva 20, Switzerland.) 


(Non-Government standards and other publications are normally available from the organizations 
that prepare or distribute the documents. These documents also may be available in or through 
libraries or other informational services.) 


2.4 Order of precedence. 
In the event of a conflict between the text of this document and the references cited herein, the 


text of this document takes precedence. Nothing in this document, however, supersedes 
applicable laws and regulations unless a specific exemption has been obtained. 


3. DEFINITIONS. 


3.1 Terms. 

Definitions of terms used in this document should be as specified in the current edition of 
FED-STD-1037, except where inconsistent with the use in this standard. In addition, the 
following definitions are applicable for the purpose of this standard. 
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High-performance HF data modem. High-speed (capable of at least 1200 bits per second) or 
robust data modes which incorporate sophisticated techniques for correcting or reducing the 
number of raw (over-the-air induced) errors. 


Phase noise (dBc/Hertz (Hz)). The amount of single-sided phase noise, contained in a 1-Hz 
bandwidth, produced by a carrier (signal generation) source, and referenced in decibels below the 
full (unsuppressed) carrier output power. 


Second generation automatic link establishment (2G ALE). ALE as first technically 
described in Appendix A of this document. 


Third generation automatic link establishment (3G ALE). ALE as first technically described 
in Appendix C of this document. 


3.2 Abbreviations and acronyms. 
The abbreviations and acronyms used in this document are defined below. Those listed in the 
current edition of FED-STD-1037 have been included for the convenience of the reader. 


2G ALE second generation automatic link establishment 

3G ALE third generation automatic link establishment 

ABCA American, British, Canadian, Australian 

AGC automatic gain control 

AJ Anti-Jam 

ALC automatic level control 

ALE automatic link establishment 

ANSI American National Standards Institute 

ARQ automatic repeat request 

b/s bits per second 

Bd baud 

C3l Command, Control, Communications, and Intelligence 
CCIR International Radio Consultative Committee 

dB decibels 

dBc decibels referenced to full-rated peak envelope power 
DII Defense Information Infrastructure 

DISA Defense Information Systems Agency 

DISAC Defense Information Systems Agency Circular 

DO design objective 

DoD Department of Defense 

DODISS Department of Defense Index of Specifications and Standards 
EMC electromagnetic compatibility 

FDM frequency division multiplex 

FEC forward error correction 

FSK frequency-shift keying 

HF high frequency 

HFNC HF Network Controller 


PI 

PQM 
PTT 
QSTAG 
RF 

RT 
SINAD 
SSB 
STANAG 
TAC 
TOD 
uncl 
USB 
VSWR 
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Hertz 

interrupted continuous wave 
intermediate frequency 
intermodulation distortion 
independent sideband 

International Telecommunications Union - Telecommunication 
Standardization Sector 

kiloHertz 

link protection 

link quality analysis 

lower sideband 

medium frequency 

megahertz 

millisecond 

North Atlantic Treaty Organization 
narrowband frequency modulation 
National Security Agency 

not tested 

National Telecommunications and Information Administration 
peak envelope power 

protection interval 

path quality matrix 

push-to-talk 

Quadripartite Standard Agreement 
radio frequency 

routing table 
signal-plus-noise-plus-distortion to noise-plus-distortion ratio 
single-sideband 

Standard Agreement 

Technical Advisory Committee 
time of day 

unclassified 

upper sideband 

voltage standing wave radio 


4. GENERAL REQUIREMENTS. 


4.1 General. 


By convention, frequency band allocation for the MF band is from 0.3 megahertz (MHz) to 3 
MHz and the HF band is from 3 MHz to 30 MHz. However, for military purposes, equipment 
designed for HF band use has been historically designed with frequency coverage extending into 
the MF band. For new HF equipment, HF band standard parameters shall apply to any portion of 
the MF band included as extended coverage. Currently there are no known military requirements 
below 1.5 MHz. Consequently, this portion of the MF band is not standardized. 
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4.1.1 Equipment parameters. 

Equipment parameters will be categorized using functional use groups for radio 
assemblages/sets. Historically, these groups have been fixed (long-haul) installations and tactical 
systems. The tactical sets are subgrouped further into vehicle transportable and manpack 
versions. Although these distinctions still exist in principle, the former lines of distinction have 
become somewhat blurred. The mobility of current military forces dictates that a significant 
number of long-haul requirements will be met with transportable systems, and in some cases, 
such systems are implemented with design components shared with manpack radios. When such 
“tactical” equipment is used to meet a long-haul requirement, the equipment shall meet long-haul 
minimum performance standards. 


4.1.2 Basic HF radio parameters. 

Basic HF radio parameters are contained in this section and in section 5. HF technology going 
beyond the basic radio is contained in the appendices. Figure 1 shows the relationship of the 
functional aspects of current HF technology in terms of the Seven Layer Reference Model. The 
shaded area in figure 1 indicates coverage in this section and section 5. 
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FIGURE 1. Physical layer with transceiver and modem elements. 


4.2 Equipment operation mode. 


4.2.1 Baseline mode. 

Frequency control of all new HF equipment, except manpack, shall be capable of being stabilized 
by an external standard. Should multiple-frequency (channel) storage be incorporated, it shall be 
of the programmable-memory type and be capable of storing/initializing the operational mode 
(see paragraphs 4.2.1.1 and 4.2.1.2 below, and paragraph A.4.3.1 of Appendix A) associated with 
each particular channel. 


4.2.1.1 Single-channel. 
All new single-channel HF equipment shall provide, as a minimum, the capability for the 


following one-at-a-time selectable operational modes: 
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a. One nominal 3-kiloHertz (kHz) channel upper sideband (USB) or lower sideband (LSB) 
(selectable). 


b. One (rate-dependent bandwidth) interrupted continuous wave (ICW) channel.* 


c. A narrowband frequency modulation (NBFM) channel capability should be included as a 
DO. 


*Not mandatory for radios designed for ALE. 
4.2.1.2 Multichannel. 
All new multichannel HF equipment shall provide a single channel capability as set forth in 
paragraph 4.2.1.1, as a minimum, and one or more of the following modes, selectable one at a 
time: 


a. Two nominal 3-kHz channels in the USB and LSB (two independent channels in the same 
sideband--sideband selectable). 


b. One nominal 6-kHz channel in the USB or LSB (selectable). 


c. Two nominal 3-kHz channels in the USB and two in the LSB (four independent 3-kHz 
channels — two in each sideband). 


d. One nominal 6-kHz channel in the USB and one in the LSB (two independent 6-kHz 
channels--one in each sideband). 


e. One nominal 3-kHz channel in the USB and one in the LSB (two independent 3-kHz 
channels--one in each sideband). 


4.2.2 Push-to-talk operation. 
Push-to-talk (PTT) operation is the most common form of interaction with MF/HF single 


sideband (SSB) radios, especially for tactical use by minimally trained, “noncommunicator” 
operators. Manual control with PTT shall be conventional; that is, the operator pushes the PTT 
button to talk and releases it to listen. 


4.2.3 ALE mode. 

Should an ALE capability be included, it shall be of the channel-scanning type and shall provide 
for contact initiation by either or both manual and automated control. Detailed requirements are 
in Appendix A. See 4.5 for the list of features required to support this operational mode. 


4.2.4 Anti-jam (AJ) mode. 


If AJ is to be implemented, the AJ capabilities and features for HF radios shall be in accordance 
with MIL-STD-188-148 and Appendix F, Anti-jam and Anti-interference Techniques. 


4.2.5 Linking protection (LP). 


If LP is to be implemented, the LP capabilities and features for HF radios shall be in accordance 
with Appendix B. 
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4.3 Interface parameters. 


4.3.1 Electrical characteristics of digital interfaces. 

As a minimum, any incorporated interfaces for serial binary data shall be in accordance with the 
provisions of MIL-STD-188-114, and any other interfaces specified by the contracting agencies. 
Such interfaces shall include provisions for request-to-send and clear-to-send signaling. The 
capability to accept additional standard interfaces is not precluded. 


4.3.2 Electrical characteristics of analog interfaces. 
See 5.3.6 and 5.4.5. 


4.3.3 Modulation and data signaling rates. 

The modulation rate (expressed in baud (Bd)) or the data signaling rate (expressed in bits per 
second (b/s)) at interface points A and A' in figure 2 shall include those contained in 
MIL-STD-188-110. 


4.4 NATO and Quadripartite interoperability requirements. 


4.4.1 Single-channel communications systems. 

If interoperation with NATO member nations is required for land, air, and maritime applications, 
single-channel HF radio equipment shall comply with the applicable requirements of the current 
edition of STANAG 4203. 


4.4.2 Maritime air communications systems. 
If interoperation with NATO member nations is required, HF maritime air communications shall 
comply with the applicable requirements of the current edition of STANAG 5035. 


I RADIO SUBSYSTEM 


INFORMATION TRANSMITTING RECEIVING INFORMATION 
SOURCE TERMINAL TERMINAL SINK 


POINT A POINT B POINT C POINT A’ 


Note: See MIL-STD 188-110 for A and A’ interface point. 


FIGURE 2. Radio subsystems interface points. 
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4.4.3 High-performance HF data modems. 
If interoperation with NATO member nations is required, land, air, and maritime, single-channel 
HF radio equipment shall comply with the applicable requirements of the appropriate STANAG. 


4.4.4 QSTAGs. 

If interoperation among American, British, Canadian, Australian (ABCA), and New Zealand 
Armies is required, HF combat net radio equipment shall comply with the applicable 
requirements of the current edition of QSTAG 733. 


4.5 Adaptive communications. 

Adaptive HF describes any HF communications system that has the ability to sense its 
communications environment, and, if required, to automatically adjust operations to improve 
communications performance. Should the user elect to incorporate adaptive features, they shall 
be in accordance with the requirements for those features stated in this document. 


The essential adaptive features are: 
a. Channel (frequency) scanning capability. 


b. ALE using an embedded selective calling capability. A disabling capability and a 
capability to inhibit responses shall be included. 


c. Automatic sounding (station-identifiable transmissions). A capability to disable sounding 
and a capability to inhibit responses shall be included. 


d. Limited link quality analysis (LQA) for assisting the ALE function: 
(1) Relative data error assessment. 
(2) Relative signal-plus-noise-plus-distortion to noise-plus-distortion ratio (SINAD). 
(3) Multipath/distortion assessment (DO) (optional). 

e. Automatic link maintenance 


f. Channel occupancy 


4.6 Linking protection. 
LP refers to the protection of the linking function required to establish, control, maintain, and 


terminate the radio link. Because this protection is applied to the link establishment function, LP 
is a data link layer function in terms of the Seven Layer Reference Model. Figure B-1, Appendix 
B shows a conceptual model of the MIL-STD-188-141 data link layer functions, showing the 
placement within the data link layer at which linking protection shall be implemented. Voice 
transmissions or data transmissions from external modems are not affected by the LP. The LP 
application levels and their corresponding protection interval (PI) are defined in Appendix B, 
paragraphs B 4.1.1 through B 4.1.1.5. 
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4.7 HF data link protocol. 
See Appendix G, HF Data Link Protocol and MIL-STD-188-110. 


4.8 Networking functions. 


a. MIL-STD-188-141 establishes the technology baseline needed for establishing and 
maintaining links among HF radio stations. Networking technology augments this direct 
connection capability with the ability to find and use indirect routes. 


b. The functions performed at the network layer may be grouped into two broad categories: 
routing functions and data management functions. Routing functions select paths through 
the network for voice and data traffic, using stored information (provided by operators, local 
data link controllers, and remote networking controllers) about the quality of available links 
to other stations. Data management functions acquire and communicate that (and other) 
information. 


c. Link-level error statistics directly characterize the quality of single-link paths and are used 
to compute end-to-end path quality for multiple-link paths through relays. These results are 
stored in a path quality matrix (PQM), which is organized to provide the path quality to any 
reachable destination via each directly-reachable relay station. From this path quality data, a 
routing table (RT) is formed. This table lists the best path to each reachable station for 
various types of communication (e.g., voice and data). 


4.8.1 Indirect calling and relaying. 

When a station cannot directly link with a desired destination, other stations may be employed to 
assist in getting the message through. The simplest option is to have the local link controller or 
the HF Network Controller (HFNC) establish a link with a station other than the desired 
destination so that the station operators can manually communicate (using either voice or data 
orderwire) after the fashion of a torn-tape relay. When the equipment at the intermediate station 
is able to automatically establish an indirect path to the destination, this is termed relaying. A 
variety of relaying techniques are possible, some of which are shown in figure 3. These 
techniques are differentiated where the cross-connection occurs in the protocol stack. Each 
alternative is briefly discussed in table I. 


4.8.2 Network management. 
See Appendix D, HF Radio Networking, and Appendix H, Management Information Base 


4.9 Application protocols for HF radio networks. 
See Appendix E, Application Protocols for HF Radio Networks. 
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| WORD REPEATER 


Rx FEC 
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(CROSS-CONNECTED TO TRANSMIT SIDE) DETERMINES TYPE OF RELAY. 


FIGURE 3. Relaying alternatives. 
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TABLE I. Relaying alternative notes. 


Radio Frequency No radios required. Examples: float a large aluminized balloon or use a billboard 
(RF) echo reflector. 


RF repeater Formed by connecting an RF amplifier between two antennas. Uses different radio 
frequencies by heterodyning or translating the received frequencies. 


VF repeater Formed by connecting two radios back-to-back through the audio ports. This and all 
following relays can easily use different radio frequencies. 


Bit repeater Formed by connecting data ports of modems. Regenerates audio and bit timing. 


Word repeater Occurs just above forward error correction (FEC) sublayer (and below LP). 
Corrects errors in data words but does not examine those words or otherwise 
manipulate their contents. Introduces one word time delay. 


Frame repeater Occurs within data link protocol sublayer. Like word repeater, but buffers an entire 
frame before retransmitting it; introduces delay of frame time plus time to detect the 
end of the frame. This and all following relays require only one radio, but can use 
more if available 


Slave router Occurs just above data link layer. Effectively connects data links in tandem as 
directed by indirect addresses in data link frames. Makes no routing decisions; 
merely implements the routing scheme specified in frames that it receives (hence the 
name). 


Router Network layer function. Determines where to send each received frame using local 
routing information; this routing information may be entirely static or it may include 
real-time data (in an adaptive router). Uses network layer message header; normally 
has access only to message section of data link layer (e.g., ALE) frame. May buffer 
data when no path currently exists to destination. 


Mailbox Application layer function. Stores messages for later retrieval by specified recipient. 


BBS Application layer function. Stores messages for later retrieval by anyone with access 
to that bulletin board system. 


5. DETAILED REQUIREMENTS. 


5.1 General. 


5.1.1 Introduction. 
This section provides detailed performance standards for MF and HF radio equipment. These 


performance standards shall apply over the appropriate frequency range from 2.0 MHz to 
29.9999 MHz (DO: 1.5 MHz to 29.9999 MHz). 


5.1.2 Signal and noise relationships. 
The signal and noise relationships are expressed as SINAD, unless otherwise identified. Unless 


otherwise specified, when the ratio is stated, the noise bandwidth is 3 kHz. 
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5.2 Common equipment characteristics. 
These characteristics shall apply to each transmitter and to each receiver unless otherwise 
specified. 


5.2.1 Displayed frequency. 
The displayed frequency shall be that of the carrier, whether suppressed or not. 


5.2.2 Frequency coverage. 

The radio equipment shall be capable of operating over the frequency range of 2.0 MHz to 
29.9999 MHz in a maximum of 100-Hz frequency increments (DO: 10-Hz) for single-channel 
equipment, and 10-Hz frequency increments (DO: 1-Hz) for multichannel equipment. 


5.2.3. Frequency accuracy. 

The accuracy of the radio carrier frequency, including tolerance and long-term stability, but not 
any variation due to doppler shift, shall be within +30 Hz for tactical application and within 
+10 Hz for all others, during a period of not less than 30 days. If tactical system include long 
haul interoperability mission, tactical equipment must meet +10° Hz radio carrier frequency 
specification. 


5.2.4 Phase stability. 
The phase stability shall be such that the probability that the phase difference will exceed 5 


degrees over any two successive 10 millisecond (ms) periods (13.33-ms periods may also be 
used) shall be less than 1 percent. Measurements shall be performed over a sufficient number of 
adjacent periods to establish the specified probability with a confidence of at least 95 percent. 


5.2.5 Phase noise. 

The synthesizer and mixer phase-noise spectrum at the transmitter output shall not exceed those 
limits as depicted in figures 4 and 5 under continuous carrier single-tone output conditions. 
Figure 4 depicts the limits of phase noise for cosited and non-cosited fixed-site and transportable 
long-haul radio transmitters. Figure 5 depicts the limits for tactical radio transmitters. If tactical 
system include long haul interoperability mission, tactical equipment must meet +10° Hz radio 
carrier frequency specification. 
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5.2.6 Bandwidths. 

The bandwidths for high frequency band emissions shall be as shown in table II. Use of other HF 
band emissions is optional, however, if selected, shall be as shown in table II. Other high 
frequency band emissions, which may be required to satisfy specific user requirements, can be 
found in the NTIA Manual of Regulations and Procedures for Federal Radio Frequency 
Management. 


TABLE II. Bandwidths. 


3 decibels (dB) 
Bandwidth (kHz) 
Frequency-shift keying (FSK) 0.3 No 
stan a ae a 
FSK 1.1 No 
ee ee 
: 


SSB modulation see 5.2.7.1 
single-channel 
Independent-sideband (ISM) modulation | | 


see 5.2.7.1 
see 5.2.7.2 


* Not mandatory for radios designed for ALE. 


5.2.7 Overall channel responses. 


5.2.7.1 Single-channel or dual-channel operation. 
The amplitude vs. frequency response between (fy + 300 Hz) and (fp + 3050 Hz) shall be within 


3 dB (total) where fo is the carrier frequency. The attenuation shall be at least 20 dB from fo to (fo 
- 415 Hz), at least 40 dB from (fp - 415 Hz) to (fo - 1000 Hz), and at least 60 dB below (fo - 1000 
Hz). Attenuation shall be at least 30 dB from (fp + 4000 Hz) to (fo + 5000 Hz) and at least 60 dB 
above (fy) + 5000 Hz). See figure 6. Group delay time shall not vary by more than 1.0 ms over 
80 percent of the passband of 300 Hz to 3050 Hz (575-2775 Hz). Measurements shall be 
performed end-to-end (transmitter audio input to receiver audio output) with the radio equipment 
configured in a back-to-back test setup. 


NOTE: Although the response values given are for single-channel USB operation, an 


identical shape, but inverted channel response, is required for LSB or the inverted channel of 
a dual-channel independent sideband operation. 
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FIGURE 6. Overall channel response for single-channel or dual-channel equipment. 


5.2.7.2 Four-channel operation. 

When four-channel independent sideband operation is employed, the four individual 3-kHz 
channels shall be configured as shown in figure 7, which also shows the amplitude response for 
these four channels. Channels A2 and B2 shall be inverted and displaced with respect to 
channels Al and B1 as shown on the figure. This can be accomplished by using subcarrier 
frequencies of 6290 Hz above and below the center carrier frequency, or by other suitable 
techniques that produce the required channel displacements and inversions. 

The suppression of any subcarriers used shall be at least 40 dB (DO: 50 dB) below the level of a 
single tone in the A2 or B2 channel modulating the transmitter to 25 percent of peak envelope 
power (PEP). See figure 7. The rf amplitude versus frequency response for each ISB channel 
shall be within 2 dB (DO: 1 dB) between 250 Hz and 3100 Hz, referenced to each channel's 
carrier (either actual or virtual). Referenced from each channel's carrier, the channel attenuation 
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shall be at least 40 dB at 50 Hz and 3250 Hz, and at least 60 dB at -250 Hz and 3550 Hz. Group 
delay distortion shall not exceed 1500 microseconds over the ranges 370 Hz to 750 Hz and 3000 
Hz to 3100 Hz. The distortion shall not exceed 1000 microseconds over the range 750 Hz to 
3000 Hz. Group delay distortion shall not exceed 150 microseconds for any 100-Hz frequency 
increment between 570 Hz and 3000 Hz. Measurements shall be performed end-to-end 
(transmitter audio input to receiver audio output) with the radio equipment configured in a back- 
to-back test setup. 


5.2.8 Absolute delay. 
The absolute delay shall not exceed 10 ms (DO: 5 ms) over the frequency range of 300 Hz to 


3050 Hz. Measurements shall be performed back-to-back as in paragraph 5.2.7.1. 


5.3 Transmitter characteristics. 


5.3.1 Noise and distortion. 


5.3.1.1 In-band noise. 

Broadband noise in a 1-Hz bandwidth within the selected sideband shall be at least 75 decibels 
referenced to full-rated peak envelope power (dBc) below the level of the rated PEP of the HF 
transmitter for fixed station application and 65 dBc below the level of the rated PEP of the HF 
transmitter for tactical application. 


5.3.1.2 Intermodulation distortion (IMD). 

The IMD products of HF transmitters produced by any two equal-level signals within the 3 dB 
bandwidth (a single-frequency audio output) shall be at least 30 dB below either tone for fixed 
station application and 24 dB below either tone for tactical application when the transmitter is 
operating at rated PEP. The frequencies of the two audio test signals shall not be harmonically or 
subharmonically related and shall have a minimum separation of 300 Hz. 
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ATTENUATION 


FIGURE 7. Overall channel characteristics (four-channel equipment). 


20 


MIL-STD-188-141B 


5.3.2 Spectral purity. 


5.3.2.1 Broadband emissions. 

When the transmitter is driven with a single tone to the rated PEP, the power spectral density of 
the transmitter broadband emission shall not exceed the level established in table III and as 
shown in figure 8. Discrete spurs shall be excluded from the measurement, and the measurement 
bandwidth shall be 1 Hz. 


TABLE III. Out-of-band power spectral density limits for radio transmitters. 


Frequency (Hz) Attenuation Below In-Band Power Density 
(dBc) 
fm = f. + (0.5 B + 500) 40 (DO: 43) 
fn =f+1.0B 45 (DO: 48) 
fn =f+2.5B 60 (DO: 80) 


(f. + 4.0 B) < fy < 1.05 f, 70 (DO: 80) 
0.95 fe < fm < (fe - 4.0 B) 


fin < 0.95 f, 90 (DO: 120) 
fn > 1.05 f, 


fm = frequency of measurement (Hz) 
f, = center frequency of bandwidth (Hz) 
B = bandwidth (Hz) 
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FIGURE 8. Out-of-band power spectral density for HF transmitters. 


5.3.2.2 Discrete frequency spurious emissions. 
For HF transmitters, when driven with a single tone to produce an rf output of 25 percent rated 


PEP, all discrete frequency spurious emissions shall be suppressed as follows: 


a. For fixed application 
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e Between the carrier frequency fe and fe + 4B (where B = bandwidth), at least 40 dBc. 


e Between fc + 4B and + 5 percent of fe removed from the carrier frequency, at least 60 
dBe. 


e Beyond +5 percent removed from the carrier frequency, at least 80 dBc. 


e Harmonic performance levels shall not exceed -63 dBc. 
See figure 10a. 


b. For tactical application 
e Between the carrier frequency f, and f,+ 4B (where B = bandwidth), at least 40 dBc. 


e Beyond f, + 4B at least 50 dBc. 


e Harmonic performance levels shall not exceed -40 dBc. 
See figure 9. 


5.3.3 Carrier suppression. 

The suppressed carrier for tactical applications shall be at least 40 dBc (DO: 60 dBc) below the 
output level of a single tone modulating the transmitter to rated PEP. The suppressed carrier for 
fixed site applications shall be at least 50 dBc (DO: 60 dBc) below the output level of a single 
tone modulating the transmitter to rated PEP. 


5.3.4 Automatic level control (ALC). 
Starting at ALC threshold, an increase of 20 dB in audio input shall result in less than a 1 dB 
increase in average rf power output. 
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SUPPRESSION (dBc) 


0.95f, f,- 4B i f, + 4B 1.05f, 
FREQUENCY 
NOTES: 
1. EMISSIONS SHALL FALL WITHIN THE UNSHADED PORTION OF THE CURVE. 
2. HARMONIC PERFORMANCE LEVELS FOR FIXED TRANSMITTERS SHALL NOT EXCEED -63dBc. 


MIT FOR FIXED HF TRANSMITTERS. 


SUPPRESSION (dBc) 


f,-4B f, f+ 4B 
FREQUENCY 


NOTES: 
1. EMISSIONS SHALL FALL WITHIN THE UNSHADED PORTION OF THE CURVE. 
2. HARMONIC PERFORMANCE LEVELS FOR TACTICAL TRANSMITTERS SHALL NOT EXCEED -40dBc. 


b. DISCRETE SPURIOUS EMISSIONS LIMIT FOR TACTICAL HF TRANSMITTERS. 


FIGURE 9. Discrete spurious emissions limit for HF transmitters. 
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5.3.5 Attack and release time delays. 


5.3.5.1 Attack-time delay. 

The time interval from keying-on a transmitter until the transmitted rf signal amplitude has 
increased to 90 percent of its steady-state value shall not exceed 25 ms (DO: 10 ms). This delay 
excludes any necessary time for automatic antenna tuning. 


5.3.5.2 Release-time delay. 
The time interval from keying-off a transmitter until the transmitted rf signal amplitude has 
decreased to 10 percent of its key-on steady-state value shall be 10 ms or less. 


5.3.6 Signal input interface characteristics. 


5.3.6.1 Input signal power. 

Input signal power for microphone or handset input is not standardized. When a line-level input 
is provided (see paragraph 5.3.6.2), rated transmitter PEP shall be obtainable for single tone 
amplitudes from -17 dBm to +6 dBm (manual adjustment permitted). 


5.3.6.2 Input audio signal interface. 


5.3.6.2.1 Unbalanced interface. 

When an unbalanced interface is provided, it shall have an audio input impedance of a nominal 
150 ohms, unbalanced with respect to ground, with a minimum return loss of 20 dB against a 
150-ohm resistance over the nominal 3 kHz passband. 


5.3.6.2.2 Balanced interface. 

When a balanced interface is provided, the audio input impedance shall be a nominal 600 ohms, 
balanced with respect to ground, with a minimum return loss of 26 dB against a 600-ohm 
resistance over the frequency range of 300 Hz to 3050 Hz. The electrical symmetry shall be 
sufficient to suppress longitudinal currents at least 40 dB below the reference signal level. 


5.3.7 Transmitter output load impedance. 

The nominal rf output load impedance at interface point B in figure 2 shall be 50 ohms, 
unbalanced with respect to ground. Transmitters shall survive any voltage standing wave radio 
(VSWR) at point B, while derating the output power as a function of increasing VSWR. 
However, the transmitter shall deliver full rated forward power into a 1.3:1 VSWR load. Figure 
11 is a design objective for the derating curve. The VSWR between an exciter and an amplifier 
shall be less than 1.5:1. The VSWR between an amplifier and an antenna coupler shall be less 
than 1.5:1 for fixed applications and less than 2.0:1 for tactical application. 
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FIGURE 10. Output power vs. VSWR for transmitters with broadband output impedance 


networks. 


NOTE: The full-rated output power of a transmitter over the operating frequency range is 
defined to be (a) the rated PEP when the transmitter is driven by a two-tone signal 
consisting of equal amplitude tones, and (b) the rated average power when driven by a 
single tone. The output rating shall be determined with the transmitter operating into a 
50-ohm load. 
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5.4 Receiver characteristics. 


5.4.1 Receiver rf characteristics. 
All receiver input amplitudes are in terms of available power in dBm from a 50-ohm source 
impedance signal generator. 


5.4.1.1 Image rejection. 
The rejection of image signals shall be at least 70 dB for tactical HF receivers and 80 dB for all 
other HF receivers (DO: 100 dB). 


5.4.1.2 Intermediate frequency (IF) rejection. 
Spurious signals at the IF (frequencies) shall be rejected by at least 70 dB for tactical HF 
receivers and 80 dB for all other HF receivers (DO: 100 dB). 


5.4.1.3 Adjacent-channel rejection. 
The receiver shall reject any signal in the undesired sideband and adjacent channel in accordance 
with figure 6. 


5.4.1.4 Other signal-frequency external spurious responses. 

Receiver rejection of spurious frequencies, other than IF and image, shall be at least 65 dB (55 
dB for tactical application) for frequencies from +2.5 percent to +30 percent, and from -2.5 
percent to -30 percent of the center frequency, and at least 80 dB (70 dB for tactical application) 
for frequencies beyond +30 percent of the center frequency. 


5.4.1.5 Receiver protection. 

The receiver, with primary power on or off, shall be capable of survival without damage with 
applied signals of up to +43 dBm (DO: +53 dBm) available power delivered from a 50-ohm 
source for a duration of 5 minutes for fixed site applications and 1 minute for tactical 
applications. 


5.4.1.6 Desensitization dynamic range. 

The following requirement shall apply to the receiver in an SSB mode of operation with an IF 
passband setting providing at least 2750 Hz (nominal 3 kHz bandwidth) at the 2 dB points. With 
the receiver tuning centered on a sinusoidal input test signal and with the test signal level 
adjusted to produce an output SINAD of 10 dB, a single interfering sinusoidal signal, offset from 
the test signal by an amount equal to +5 percent of the carrier frequency, is injected into the 
receiver input. The output SINAD shall not be degraded by more than | dB as follows: 


a. For fixed site radios, the interfering signal is equal to or less than 100 dB above the test 
signal level. 


b. For tactical radios, the interfering signal is equal to or less than 90 dB above the test 
signal level. 
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5.4.1.7 Receiver sensitivity. 

The sensitivity of the receiver over the operating frequency range, in the sideband mode of 
operation (3-kHz bandwidth), shall be such that a -111 dBm (DO: -121 dBm) unmodulated signal 
at the antenna terminal, adjusted for a 1000 Hz audio output, produces an audio output with a 
SINAD of at least 10 dB over the operating frequency range. 


5.4.1.8 Receiver out-of-band IMD. 

Second-order and higher-order responses shall require a two-tone signal amplitude with each 
tone at -30 dBm or greater (-36 dBm or greater for tactical applications), to produce an output 
SINAD equivalent to a single -110 dBm tone. This requirement is applicable for equal- 
amplitude input signals with the closest signal spaced 30 kHz or more from the operating 
frequency. 


5.4.1.9 Third-order intercept point. 
Using test signals within the first IF passband, the worst-case third-order intercept point shall not 
be less than +10 dBm (+1 dBm for tactical applications). 


5.4.2 Receiver distortion and internally generated spurious outputs. 


5.4.2.1 Overall IMD (in-channel). 

The total of IMD products, with two equal-amplitude, in-channel tones spaced 110 Hz apart, 
present at the receiver rf input, shall meet the following requirements. However, for frequency 
division multiplex (FDM) service, the receiver shall meet the requirements for any tone spacing 
equal to or greater than the minimum between adjacent tones in any FDM library. The 
requirements shall be met for any rf input amplitude up to 0 dBm PEP (-6 dBm/tone) at rated 
audio output. All IMD products shall be at least 35 dB (DO: 45 dB) below the output level of 
either of the two tones. 


5.4.2.2 Adjacent-channel IMD. 

For multiple-channel equipment, the overall adjacent-channel IMD in each 3 kHz channel being 
measured shall not be greater than -35 dBm at the 3 kHz channel output with all other channels 
equally loaded with 0 dBm unweighted white noise. 


5.4.2.3, Audio frequency total harmonic distortion. 

The total harmonic distortion produced by any single-frequency rf test signal, which produces a 
frequency within the frequency bandwidth of 300 Hz to 3050 Hz shall be at least 25 dB (DO: 35 
dB) below the reference tone level with the receiver at rated output level. The rf test signal shall 
be at least 35 dB above the receiver noise threshold. 


5.4.2.4 Internally generated spurious outputs. 

For 99 percent of the available 3 kHz channels, internally generated spurious signals shall not 
exceed -112 dBm. For 0.8 percent of the available 3 kHz channels, spurious signals shall not 
exceed -100 dBm for tactical applications and -106 dBm for fixed applications. For 0.2 percent 
of the available 3 kHz channels, spurious signals may exceed these levels. 
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5.4.3 Automatic gain control (AGC) characteristic. 

The steady-state output level of the receiver (for a single tone) shall not vary by more than 3 dB 
over an rf input range from -103 dBm to +13 dBm for fixed application or -103 dBm to 0 dBm 
for tactical application. 


5.4.3.1 AGC attack time (nondata modes). 
The receiver AGC attack time shall not exceed 30 ms. 


5.4.3.2 AGC release time (nondata modes). 

The receiver AGC release time shall be between 800 and 1200 ms for SSB voice and ICW 
operation. This shall be the period from rf signal downward transition until audio output is 
within 3 dB of the steady-state output. The final steady-state audio output is simply receiver 
noise being amplified in the absence of any rf input signal. 


5.4.3.3, AGC requirements for data service. 
In data service, the receiver AGC attack time shall not exceed 10 ms. The AGC release time 
shall not exceed 25 ms. 


5.4.4 Receiver linearity. 

The following shall apply with the receiver operating at maximum sensitivity, and with a 
reference input signal that produces a SINAD of 10 dB at the receiver output. The output 
SINAD shall increase monotonically and linearly within + 1.5 dB for a linear increase in input 
signal level until the output SINAD is equal to at least 30 dB (DO: 40 dB). When saturation 
occurs, the output SINAD may vary +3 dB for additional increase in signal level. This 
requirement shall apply over the operating frequency range of the receiver. 


5.4.5 Interface characteristics. 


5.4.5.1 Input impedance. 

The receiver rf input impedance shall be nominally 50 ohms, unbalanced with respect to ground. 
The input VSWR, with respect to 50 ohms, shall not exceed 2.5:1 over the operating frequency 
range. 


5.4.5.2 Output impedance and power. 

When a balanced output is provided, the receiver output impedance shall be a nominal 600 ohms, 
balanced with respect to ground, capable of delivering 0 dBm to a 600-ohm load. Electrical 
symmetry shall be sufficient to suppress longitudinal currents at least 40 dB below reference 
signal level. The receiver output signal power for operation with a headset or handset shall be 
adjustable at least over the range from -30 dBm to 0 dBm. For operation with a speaker, the 
output level shall be adjustable at least over the range of 0 dBm to +30 dBm. As a DO, an 
additional interface can accommodate speakers ranging from 4 to 16 ohms impedance should be 
provided. 
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5.5 ALE. 


5.5.1 Basic ALE (2G). 

If ALE is to be implemented, it shall be in accordance with appendix A. The ALE requirements 
include selective calling and handshake, link quality analysis and channel selection, scanning, 
and sounding. These requirements are organized in Appendix A as follows: 


a. Requirements for ALE implementation are given in sections A-1 through A-4. 


b. Detailed requirements on ALE waveform, signal structure protocols, and ALE control 
function (orderwire messages) are contained in section A-5. 


5.5.2 3G ALE. 
This improved more capable ALE may be implemented in addition to, but not in lieu of, Basic 
ALE. The technical requirements for 3G ALE are contained in Appendix C. 


5.6 LP. 
If linking protection is required to be implemented, it shall be in accordance with appendix B. 
These requirements are organized in Appendix B as follows: 


a. General requirements for LP implementation are given in sections B-1 through B-4. 
b. Detailed requirements on how to implement LP are given in section B-S. 


c. The unclassified application level (AL-1) is the lowest level of LP and is mandatory for 
all protected radios implementing LP. 


d. The unclassified enhanced application level (AL-2) is the highest level of LP covered in 
Appendix B. The algorithms for the higher levels of LP, application levels AL-3 and AL-4, 
are defined in National Security Agency (NSA) classified documents. 


e. The 24-bit encryption algorithm for linking protection applies to 2nd generation systems 
(Appendix B, Annex A) and the SODARK algorithm applies to 3rd generation systems 
(Appendix B, Annex B). 


5.7 ALE control functions (orderwire functions). 
See Appendix A, paragraphs A 5.6 and A 5.7. 


5.8 Networking functions. 
See Appendix D. 


5.9 Network management. 
See Appendix D. 


5.10 HF application interface. 
See Appendix E. 
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5.11 Data link protocol. 
See Appendix F. 


5.12 Anti-jam capability. 
See Appendix G. 


5.13 Automatic repeat request (ARQ) protocol. 
See Appendix H. 


6. NOTES. 
This section contains information of a general or explanatory nature that may be helpful, but is 
not mandatory. 


6.1 Intended use. 


a. This standard contains requirements to ensure interoperability of new radio equipment 
with long-haul and tactical application in the medium frequency (MF) band and in the high 
frequency (HF) band. 


b. There is no requirement for linking protection to be a part of a user’s acquisition unless 
the user has an identified need. Optional levels of linking protection are identified and 
detailed. Options AL-1 and AL-2 provide an inexpensive, least protected mode, and AL-3 
and AL-4 provide more sophisticated protection modes. The users should establish their 
application level based on minimum essential requirements. 


c. There is no requirement for the user to acquire any of the advanced technology defined in 
the appendices to this document unless the user has an identified requirement. 


6.2 Interaction matrix. 

The complexity of the adaptive features and functions may be confusing to the user of this 
standard. Certain parts of the technical features are dependent on other features defined within 
this standard and MIL-STD-187-721. This dependency is not always apparent to the user or the 
acquisition activity. The matrix shown in Table IV provides the interaction dependencies known, 
as of the publication date. 


31 


MIL-STD-188-141B 


TABLE IV. Interaction matrix: General features. 


Paragraph 


1. Automated Appendix D HNMP [28] and HF MIB [29] 

Network MIL-STD-188-141 

Management D.4.4 and D.5.3 

2. Remote HNMP [28] and HF MIB [29] *Feature supported, but no paragraph with this 
Control Of title. 

Station 

Equipment 


pee te HNMP [28] and HF MIB [29] *Feature supported, but no paragraph with this 
Fill title 


4. Any-Media Appendix D IP [14], AME [24] (for use of HF) Robust networking using all available media; 
Networking MIL-STD-188-141 | HRMP [26] and HSSP [27] (for topology | CONEX [19] is also useful. 
D.4.5 and D.5.5 monitoring) Robust networking using all 

available media CONEX [19] is also 

useful. 
5. Fully- Message Store and Forward [22], Route *Level 2 HFNC [16] provides the features for 
Automated Selection [20] fully-automated (but not adaptive) message 
Message handling. 
Handling 
6. Adaptive Routing Queries [7] *Path Quality Matrix [18] and CONEX [19] 
Routing provide increased functionality, with increased 


overhead. 
7. Routing MIL-STD-188-141 | HRMP [26] 
8. Connectivity MIL-STD-188-141 | HRMP [26] HSSP [27] recommended also. 
9. Repeater MIL-STD-188-141 | HRMP [26] 
10. Full-Duplex 5.6.3 Frequency Select Command [35] 


Independent 
Operation 


Services RFCs) 
12. TCP x IP [14] and either 3G Data Link Protocol | *Defined in RFC-793 Do not use over HF 


15. Indirect 4.8 and D.5.2.2 ALE controller (for Link Establishment) Level 2 (or higher) HFNC [16] recommended 
Calling for selection alternate station. 


16. HFNC D.4.2 (See Table D-II for levels of functional SDLP [31] recommended for link controller 
capability) Requires at least one link interface. FED-STD-1052 modem and 
controller, including ALE, HFDLP [32], HFDLP [32] recommended for message 
or other media. transfer over HF links (versus ALE modem 

with DTM [49] or DBM [48]) 


me [psa eT 
Table D.5.2.1.2 
Matrix D.5.2.1.1 update path qualities. 

instead use only link control. 
a a 
Selection 
Layer Header 
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Interaction matrix: General features (continued). 
| Feature | _—s Paragraph =| —C‘Rquires, | —C—“‘“NHS SC 


22. Message AME [24] 
Store And 
Forward 
fet eo ee 
And Forward 
24. AME D.4.2.4 AME Protocol [25], and either Message Automatic Message Exchange 
Store and Forward [22] or Null Store and 
Forward [23] 


25. AME Network Layer Header [21] Automatic Message Exchange. Works best 
Protocol with 3G modems and protocols [60] or FED- 
STD-1052 modem and HFDLP [32]. 


26. HRMP D.5.2.6 Network Layer Header [21] HF Relay Management Protocol. Works best 
with 3G modems and protocols [60] or FED- 
STD-1052 modem and HFDLP [32]. 
27. HSSP D.5.2.7 Network Layer Header [21] HF Station Status Protocol. Works best with 
3G modems and protocols [60] or FED-STD- 
1052 modem and HFDLP [32]. 
28. HNMP D.5.3.2 AME [24] for HF Links; UDP [13] and HF Network Management Protocol. Works 
IP [14] when using Internet; best with 3G modems and protocols [60] or 
UDP+IP+AME when internetworking via | FED-STD-1052 modem and HFDLP [32]. 
HF. 


ee lager 
Appendix H 
Link Controllers interface to link controllers. 
P31. SDLP [D540 Station Data Link Protocol 
32. HFDLP Appendix H MIL-STD-188-110-serial-tone modem. HF Data Link Protocol will work over other 
FS-1052 modems, but is optimized for the 
MIL-STD-188-110 serial-tone modem. 
33. LP Time Exchange Protocol [34] (for 
synchronization). 


34. Time Time service protocol is usually sufficient for 

Exchange : 

Protocol 

Select Command [36] 

Designators 

Designators 

38. LQA Matrix At least one source of data: Basic LQA LQA Matrix is required in MIL-STD-188-141 
[51], Polling [41], LQA Reporting [45], ALE controllers. 
or ALQA [47]. 


39. Passive LQA ALE Controller 
40. Sounding ALE Controller 


At least one Polling Protocol from [24- 
26] 
Poll 


43. Multistation, ALE Controller that supports Star Net 
Single-channel Calls [53] or Star Group Calls [52] 
Polling 
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Interaction matrix: General features (continued) 
| _ Feature || _—s Paragraph =| ——C‘éRquires | CC“ Sd 


44. Two-station, ALE Controller Frequency Designators [36] or Channel 
Single-channel Designator [37] required to select channels 
Polling outside current scan list. 


45. ALQA 4 LQA Report Protocol [46] 
Reporting 


4.3 
46. LQA Report 5.4.4 MIL-STD-188-141 ALE Controller with | Frequency Designators [36] or Channel 
Protocol LQA Matrix [38], and either DTM [49] Designators [37] required to report channels 
OR DBM [48]. outside current scan list. 


48. DBM A.5.7.4 ALE Controller Data Block Message Greater throughput than 


A.5.4.2 
endl i sa A 
Calls 
a) 


53. Star Net Calls | A.5.5.3 ALE Controller 


54. Individual A.5.5.2 ALE Controller 
Calls 


55. Allcalls A.5.5.5 Individual Calls 
56. Anycalls A.5.5.6 Individual Calls PO 


See a cc | 
Addressing 
| 58. Sounding [A530 ALEController 


60. 3G Link Appendix C 3G ALE [61], 3G Data Link Protocols 
Fe nl eae [62], and 3G Modem [63] networks and data applications. 

62. 3G Data Link | C.4.7 3G ALE [61], 3G TM [64], 3G ARQ High performance data link protocols, 
RPE [rete ere joo, Satan 

63. 3G Modem C.5.1 Radio Scalable suite of waveforms for various 
aie Se ee eee) 

64. 3G TM. C.5.3 3G ALE [61], 3G Modem (BW1) [63] Traffic Management protocol; coordinates 
ae i co kanal rere rae 

65. 3G ARQ C.5.4, C.5.5 3G ALE [61], 3G TM [64], 3G Modem 

links). 


6.3 Issue of DODISS. 
When this standard is used in acquisition, the applicable issue of the DODISS must be cited in 
the solicitation (see 2.2.1 and 2.2.2). 


6.4 Subject term (key word) listing. 


Adaptive communications 
AJ mode 

ALE 

ALE control functions 
ALE message protocol 
ALE mode 
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ALE 

Automatic sounding 
Baseline mode 

Deep interleaving 
Forward error correction 
Golay coding 

Leading redundant word 
Linking protection 

LQA 

Network functions 
Network management 
Protection interval 
Radio frequency scanning 
Selective calling 

Slotted responses 

Star net and group 
Triple redundant words 
Word phase 


6.5 International standardization agreements. 

Certain provisions of this standard in paragraphs 4.2, 4.4, 5.2, 5.3, and 5.4 are the subject of 
international standardization agreements, STANAGs 4203 and 5035, and QSTG 733. When 
change notice, revision, or cancellation of this standard is proposed that will modify the 
international agreement concerned, the preparing activity will take appropriate action through 
international standardization channels, including departmental standardization offices, to change 
the agreement or make other appropriate accommodations. 


6.6 Electromagnetic compatibility (EMC) requirements. 
All services and agencies are responsible for their own EMC programs, which are driven by their 
user requirements and doctrine. 


HF radio has significant inherent EMC implications that requires serious consideration by 
designers, users, and acquisition personnel. It is strongly recommended that all users of this 
standard refer to the following documents prior to design or acquisition of HF radio systems or 
equipment: 


a. MIL-STD-461, Requirements for the Control of Electromagnetic Interface Emissions and 
Susceptibility. 


b. MIL-STD-462, Measurement of Electromagnetic Interference Characteristics. 


c. MIL-HDBK-237, Electromagnetic Compatibility Management Guide for Platform, 
Systems and Equipment. 


The applicable portions of these documents should be included in any acquisition actions for HF 
radio systems or equipment. 
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AUTOMATIC LINK ESTABLISHMENT SYSTEM 


A.1 GENERAL. 


A.1.1 Scope. 

This appendix provides details of the prescribed waveform, signal structures, protocols, and 
performance requirements for the second generation (2G) automatic link establishment (ALE) 
system. 


A.1.2 Applicability. 
This appendix is a mandatory part of MIL-STD-188-141 whenever ALE is a requirement to be 


implemented into the high frequency (HF) radio system. The functional capability described 
herein includes automatic signaling, selective calling, automatic answering, and radio frequency 
(rf) scanning with link quality analysis (LQA). The capability for manual operation of the radio 
in order to conduct communications with existing, older generation, non-automated manual 
radios, shall not be impaired by implementation of these automated features. 


A.2 APPLICABLE DOCUMENTS. 


A.2.1 General. 

The documents listed in this section are specified in A.3, A.4, and A.5 of this standard. This 
section does not include documents cited in other sections of this standard or recommended for 
additional information or as examples. While every effort has been made to ensure the 
completeness of this list, document users are cautioned that they must meet all specified 
requirements documents cited in A.3, A.4, and A.5 of this standard, whether or not they are 
listed. 


A.2.2 Government documents. 


A.2.2.1 Specifications, standards, and handbooks. 
The following specifications, standards, and handbooks form a part of this document to the 


extent specified herein. Unless otherwise specified, the issues of these documents are those 
listed in the issue of the Department of Defense Index of Specifications and Standards (DODISS) 
and supplement thereto, cited in the solicitation. 
STANDARDS 
FEDERAL 
Federal Information Processing Standards 


FIPS PUB 1-1 Publication Code: for Information Interchange 
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FEDERAL STANDARDS 


FED-STD-1003 Telecommunications: Synchronous Bit 
Orientation Data Link Control Procedures 
(Advanced Data Communications Control 


Procedures) 
FED-STD-1037 Telecommunications: Glossary of 
Telecommunications Terms 
DEPARTMENT OF DEFENSE 
MIL-STD-188-110 Interoperability and Performance Standards for 


HF Data Modems 


(Copies of Federal Information Processing Standards (FIPS) are available at Standardization 
Document Order Desk, 700 Robbins Avenue, Building #4, Section D, Philadelphia, PA 19111- 
5094. Non-Department of Defense (DoD) users must request copies of FIPS from the National 
Technical Information Service, 5285 Port Royal Road, Springfield, VA 22161-2171.) 


A.2.3 Non-Government publications. 
The following documents form a part of this appendix to the extent specified: 


INTERNATIONAL STANDARDIZATION DOCUMENTS 
North Atlantic Treaty Organization (NATO) Standardization Agreements 


(STANAGs) 
STANAG 4285 Characteristics of 1200/2400/3600 bps Single 
Tone Modems for HF Radio Links 
STANAG 4529 Characteristics of Single Tone 


Modulators/Demodulators for Maritime HF 
Radio Links with 1240 Hz Bandwidth 


International Telecommunications Union (ITU), 
Radio Regulations 
ITU-R F.520-2 Recommendation for Fixed Service, use of 
High Frequency Ionospheric Channel 
Simulators 


(Application for copies should be addressed to the General Secretariat, International Organization 
for Standardization (ISO) 1, Rue de Varembe, CH-1211 Geneva 20, Switzerland.) 


Other Publications 
NMSU-EE-CD-001 Wireless Network Waveform Samples 
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(Application for copies should be addressed to New Mexico State University, Klipsch School of 
Electrical and Computer Engineering, University Park, NM 88003, Attn: Dr. E. E. Johnson.) 


(Non-Government standards and other publications are normally available from the organizations 
that prepare or distribute the documents. These documents also may be available in or through 
libraries or other informational services.) 


A.3 DEFINITIONS. 


A.3.1 Terms. 

Definitions of terms used in this document shall be as specified in the current edition of 
FED-STD-1037 except where inconsistent with the use in this standard. In addition, the 
following definitions are applicable for the purpose of this standard. 


e Available State. An ALE controller is in the available state when it does not currently 
have a link with any other station, and is not in the process of establishing a link. An 
ALE controller that is programmed for multichannel scanning operation will be scanning 
when it is in the available state. Single-channel controllers will remain tuned to the 
assigned channel regardless of their state. 


e Exclusive OR.. Used as a check, the condition that exits when each resulting bit is a “1” 
if the two input bits do not match, or the resulting bit is a “0” when the two input bits 
match. 


e Linking State. An ALE controller enters the linking state from the available state when it 
sends or receives an ALE call frame. Scanning controllers stop scanning when they enter 
the linking state. An ALE controller returns to the available state if the linking attempt 
does not complete successfully. Upon successful completion of a three-way handshake, 
controllers in the linking state enter the linked state. 


e Linked State. An ALE controller is considered to be in the linked state if it has 
successfully completed link establishment with one or more stations, and at least one link 
to which it is party has not been terminated. While in the linked state, a wait-for-activity 
timer will be running (if not disabled by the operator). Controllers programmed to scan 
will not be scanning while in the linked state. After link establishment, communication 
among linked stations normally is carried by additional three-way handshakes, but 
controllers remain in the linked state during these handshakes. 


A.3.2 Abbreviations and acronyms. 
The abbreviations and acronyms used in this document are defined below. Those listed in the 


current edition of FED-STD-1037 have been included for the convenience of the reader. 


2G ALE second generation automatic link establishment 
3G ALE second generation automatic link establishment 
ACK acknowledge character 
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AMD 
AQC 
AQC 
AQC-ALE 
ARQ 
ASCII 
AWGN 
b/s 
BCD 
BER 
CCIR 
chps 
CMD 
CRC 
dB 
DBM 
dBw 
DC 
DCE 
DO 
DoD 
DODISS 
DTE 
DTM 
eg, 
FCS 
FEC 
FIPS 
FSK 
HF 
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automatic gain control 

automatic link establishment 

automatic message display 

Alternative Quick Call 

Alternative Quick Call 

Alternative Quick Call Automatic Link Establishment 
automatic repeat request 

American Standard Code for Information Interchange 
Additive white gaussian noise 

bits per second 

binary coded decimal 

bit error ratio 

International Radio Consultative Committee 
channels per second 

ALE preamble word COMMAND 

cyclic redundancy check 

Decibel 

data block message 

dB referred to 1 W (watt) 

data code 

data circuit-terminating equipment 
design objective 

Department of Defense 

Department of Defense Index of Specifications and Standards 
data terminal equipment 

data text message 

for example 

frame check sequence 

forward error correction 

Federal Information Processing Standards 
frequency shift keying 

high frequency 

high frequency node controller 

hertz 

identification 

if and only if 

Integrated Services Digital Network 
Organization of Standardization 
International Telecommunications Union 
Kilohertz 

linking protection 

link quality analysis 
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LSB (1) lower sideband 

(2) least significant bit 
MF medium frequency 
MHz megahertz 
MP multipath 
ms millisecond 
MSB most significant bit 
NAK negative-acknowledge character 
NATO North Atlantic Treaty Organization 
NT Not Tested 
PL probability of linking 
PPM parts per million 
REP ALE preamble word REPEAT 
rf radio frequency 
RX receive 
S second 
SCTY Security 
SINAD signal-plus-noise-plus-distortion to noise-plus-distortion ratio 
SN Slot Number 
SNR signal to noise ratio 
SPS symbols per second 
SSB single-sideband [transmission] 
TDMA time-division multiple access 
TIS ALE preamble word THIS IS 
TOD time of day 
TWAS ALE preamble word THIS WAS 
TX transmit 
UI unique index 
USB upper sideband 
UUF user unique function 
UUT units under test 
WRIT wait for response and tune timeout 
WS AQC-ALE Word Syne word 


A.3.3 Definitions of timing symbols. 
The abbreviations and acronyms used for timing symbols are contained in annex A to this 
appendix. 


A.4 GENERAL REQUIREMENTS. 


A.4.1 ALE introduction. 
The techniques specified in this appendix employ a robust modem and forward error correction 
coding and constitutes a digital ALE data link. The exchange of such ALE words according to 
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the specified protocols supports channel evaluation, selective calling, and passing data messages 
and constitute an ALE data link layer. (The ALE modem, radio, coupler, antenna, and so on 
constitute the corresponding physical layer.) 


The ALE data link layer contains three sublayers, as shown in figure A-1: a lower sublayer 
concemed with error correction and detection (forward error correction [FEC] sublayer), an 
upper sublayer containing the ALE protocol (ALE sublayer), and a linking protection (LP) 
sublayer between. Within the FEC sublayer are redundancy and majority voting, interleaving, 
and Golay coding applied to the 24-bit ALE words which constitute the (FEC sublayer) service- 
data-unit, in terms of the Seven Layer Reference Model. The ALE sublayer specifies protocols 
for link establishment, data communication, and rudimentary LQA based on the capability of 
exchanging ALE words. The shaded area of figure A-1 indicates the contents of this appendix. 


The following paragraphs specify the general requirements for ALE operation. 


A.4.1.1 ALE addresses. 
Stations designed to this appendix shall employ the addressing structure specified in A.5.2.4 to 
identify individual stations and collections of stations (nets and groups). 


A.4.1.2 Scanning. 

The radio system shall be capable of repeatedly scanning selected channels stored in memory (in 
the radio or controller) under either manual control or under the direction of any associated 
automated controller. The radio shall stop scanning and wait on the most recent channel upon 
the occurrence of any of the following selectable events: 


e Automatic controller decision to stop scan (the normal mode of operation) 
e Manual input of stop scan 


e Activation of external stop-scan line (if provided) 


The scanned channels should be selectable by groups (often called “scan lists”) and also 
individually within the groups, to enable flexibility in channel and network scan management. 
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sig 


SEVEN LAYER 
MODEL 


APPLICATION 
LAYER 


PRESENTATION 
LAYER 


SESSION 
LAYER 


TRANSPORT 
LAYER 


NETWORK 
LAYER 


DATALINK 
LAYER 


PHYSICAL 
LAYER 


FIGURE A-1. Data link with ALE and FEC sublayers. 


A.4.1.3 Calling. 
Upon request by the operator or an external automated controller, the radio system shall execute 
the appropriate calling protocol specified in A.5.5. 


A.4.1.4 Channel evaluation. 

The radio system shall be capable of automatically transmitting ALE sounding transmissions in 
accordance with A.5.3, and shall automatically measure the signal quality of ALE receptions in 
accordance with A.5.4.1. 


A.4.1.5 Channel quality display. 
If an operator display is provided, the display shall have a uniform scale, 0-30 with 31 being 
unknown all based on signal-plus-noise-plus-distortion to noise-plus-distortion (SINAD). 


54 


MIL-STD-188-141B 
APPENDIX A 


A.4.2 System performance requirements. 
Stations designed to this appendix shall demonstrate an overall system performance equal to or 
exceeding the following requirements. 


A.4.2.1 Scanning rate. 
Stations designed to this appendix shall incorporate selectable scan rates of two and five channels 


per second, and may also incorporate other scan rates (design objective (DO): 10 channels per 
second). 


A.4.2.1.1 Alternative Quick Call (AQC) (NT). 
In the optional AQC-ALE protocol, the system shall be capable of variable dwell rates while 
scanning such that traffic can be detected in accordance with table A-II Probability of Linking. 


A.4.2.1.2 Recommendation. 

Radios equipped with the optional AQC-ALE shall provide scanning at scan rates of two 
channels per second or five channels per second for backward compatibility to non-AQC-ALE 
networks. 


A.4.2.2 Occupancy detection - not tested (NT). 

Stations designed to this appendix shall achieve at least the following probability of detecting the 
specified waveforms (See A.5.4.7) under the indicated conditions, with false alarm rates of no 
more than | percent. The channel simulator shall provide additive white gaussian noise 
(AWGN) without fading or multipath (MP). See table A-I. 


TABLE A-I. Occupancy detection probability (2G and 3G). 


Waveform SNR (GB in 3 kHz) Dwell Time (s) Detection Prob 


SSB Voice 
MIL-STD-188-110 
(Serial Tone PSK) 


STANAG 4529 


STANAG 4285 
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Baseband HF Channel Rx 
Baseband Signal Source Simulator Audio ALE Controller UUT 


NOTES: 
1. The single side-band (SSB) voice test signal shall be taken from The Wireless Network Samples 
NMSU-EE-CD-021. 
2. The PSK test signal shall be taken from The Wireless Network Samples NMSU-EE-CD-021. 


FIGURE A-2. Occupancy detection test setup. 


ALE TX AUDIO 


CONTROLLER 


sk CONTROL RF 


“ OUT/IN 


RX AUDIO 
UUT #1 KEYED 


UUT #1 KEYED 
HF CHANNEL 


SIMULATOR 100 dB 
(BASEBAND) ATTENUATION 


(SEE NOTE) 
UUT #2 KEYED 


UUT #2 KEYED 
RX AUDIO 


TX AUDIO 


CONTROL 


NOTE: THE SIMULATOR INCLUDES EITHER INTERNAL OR EXTERNAL CAPABILITY TO 
ADJUST/MONITOR SIGNAL/NOISE/DOPPLER-OFFSET SETTINGS AND SHALL INCORPORATE 
APPROPRIATE FILTERING TO LIMIT THE AUDIO PASSBAND TO 300 - 3050 Hz. 


FIGURE A-3. System performance measurements test setup. 


A.4.2.3 Linking probability. 

Linking attempts made with a test setup configured as shown in figure A-3, using the specified 
ALE signal created in accordance with this appendix, shall produce a probability of linking as 
shown in table A-II. 
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TABLE A-II. Probability of pureed 


9 of Gaussian Noise Modified Modified 
Linking (PI) Channel as Good Channel | CCIR Poor Channel 


Multipath (millisecond) 0.0 0.52 2,2: 
Doppler spread (Hertz) 0.0 0.10 1.0 


The receive audio input to the ALE controller shall be used to simulate the three channel 
conditions. The modified International Radio Consultative Committee (CCIR) good channel 
shall be characterized as having 0.52 millisecond (ms) (modified from 0.50ms) MP delay and a 
fading (two sigma) bandwidth of 0.1 hertz (Hz). The modified CCIR poor channel, normally 
characterized as consisting of a circuit having 2.0 ms MP delay with a fading (two sigma) 
bandwidth of 1.0 Hz, shall be modified to have 2.2 ms MP delay and a fading (two sigma) 
bandwidth of 1.0 Hz. Doppler shifts of +60 Hz shall produce no more than a 1.0 decibel (dB) 
performance degradation from the requirements of table A-II for the modified CCIR good and 
poor channels. 


NOTE: This modification is necessary due to the fact that the constant 2-ms MP delay (an 
unrealistic fixed condition) of the CCIR poor channel results in a constant nulling of certain 
tones of the ALE tone library. Other tone libraries would also have some particular MP 
value, which would result in continuous tone cancellation during simulator testing. 


Each of the signal-to-noise (SNR) ratio values shall be measured in a nominal 3-kiloHertz (kHz) 
bandwidth. Performance tests of this capability shall be conducted in accordance with ITU-R 
F.520-2 Use of High Frequency Ionospheric Channel Simulators employing the C.C. Watterson 
Model. This test shall use the individual scanning calling protocol described in A.5.5.3. The 
time for performance of each link attempt shall be measured from the initiation of the calling 
transmission until the successful establishment of the link. Performance testing shall include the 
following additional criteria: 


a. The protocol used shall be the individual scanning calling protocol with only TO and TIS 
preambles. 


b. Addresses used shall be alphanumeric, one word (three characters) in length from the 38- 
character basic American Standard Code for Information Interchange (ASCII) subset. 


c. Units under test (UUTs) shall be scanning 10 channels at two channels per second, and 
repeated at five channels per seconds. 
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d. Call initiation shall be performed with the UUT transmitter stopped and tuned to the 
calling frequency. 


e. Maximum time from call initiation (measured from the start of UUT rf transmission -- not 
from activation of the ALE protocol) to link establishment shall not exceed 14.000 seconds, 
plus simulator delay time. The call shall not exceed 23 redundent words, the response three 
redundent words and the acknowledgment three redundent words. (See A.5.2.2.4 and Annex 
A). 


NOTE: Performance at the higher scan rates shall also meet the foregoing requirements and 
shall meet or exceed the probability of linking as shown in table A-II. 


A.4.2.3.1 AQC-ALE linking probability. 
When the optional AQC-ALE protocol (see details in Section A.5.8) is implemented, the 


probability of linking shall conform to table A-II with the following additional criteria: 


a. The protocol used shall be quick AQC individual calling protocol with no message 
passing. 
b. Addresses shall be one to six characters in the 38-character basic ASCII subset. 


c. Units being called shall be scanning 10 channels. 


d. Call initiation shall be performed with the UUT transmitter stopped and tuned to the 
calling frequency. 


e. The initial call probe shall not exceed 10 T,,, the call response shall not exceed 4T,y, and 
the acknowledgment shall not exceed 2 Try. 


A.4.2.3.2, AQC-ALE linking performance. 

AQC-ALE linking performance shall not be degraded in LP level | or 2. Scan rates of two or five 
channels per second may degrade performance because insufficient redundent words are emitted 
during the call probe. 


A.4.3, Required data structures. 


A.4.3.1 Channel memory. 

The equipment shall be capable of storing, retrieving, and employing at least 100 different sets of 
information concerning channel data to include receive and transmit frequencies with associated 
mode information. See table A-III. The channel data storage shall be nonvolatile. 


The mode information normally includes: 


e transmit power level 


e traffic or channel use (voice, data, etc.) 
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e sounding data 

e modulation type (associated with frequency) 
e transmit/receive modes 

e filter width (DO) 

e automatic gain control (AGC) setting (DO) 
e input/output antenna port selection (DO) 

e input/output information port selection (DO) 
e noise blanker setting (DO) 

e security (DO) 

e sounding self address(es) SA....n(DO) 


Any channel (a) shall be capable of being recalled manually or under the direction of any 
associated automated controller, and (b) shall be capable of having its information altered after 
recall without affecting the original stored information settings. 


A.4.3.2 Self address memory. 
The radio shall be capable of storing, retrieving, and employing at least 20 different sets of 


information concerning self addressing. The self-address information storage shall be 
nonvolatile. 


These sets of information include self (its own personal) address(es), valid channels which are 
associated for use, and net addressing. 


Net addressing information shall include (for each “net member” self address, as necessary) the 
net address and the associated slot wait time (in multiples of T,,). See table A-IV. (Slotted 
responses and related concepts are defined in A.5.5.4.1.) The slot wait time values are Ts,:(slot 
number (SN)) from the formula, Tswt (SN) = Tsy x SN. 


Stations called by their net call address shall respond with their associated self (net member) 
address with the specified delay (Ts,:(SN)). For example, the call is “GUY,” thus the response is 
“BEN.” 


Stations called individually by one of their self addresses (even if a net member address) shall 
respond immediately and with that address, as specified in the individual scanning calling 
protocol. 


Stations called by one of their self addresses (even if a net member address) within a group call 
shall respond in the derived slot, and with that address, as specified in the star group scanning 
protocol. Ifa station is called by one of its net addresses and has no associated net member 
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address, it shall pause and listen but shall not respond (unless subsequently called separately with 


an available self or net member address), but shall enter the linked state. 


TABLE A-III. Channel memory example. 
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TABLE A-IV. Self address memory example. 


Self (or Net Tsw(SN)= | (4) 
Member) Net Slot Wait Valid Example 
Index | Address = Time (T,) | Channels Comments _ 
SE aE EEE RTE TCE CRETE 
[senna [ee 
channels 
ac a ca A ec 
channel 
EP | a parson ine ot 
channels, preset slot unit Gare (slot I) 
cnt cl cc  veve cere ce ree a 
shanel preset slot wait-time (slot 4) 


E limited channels preset slot wait-time 
ee a ee 
ed a ee ee Fe eee 


oe 0 Be ns et 
SA20 PARTY C5-C12 2-word net only address, therefore receive only 
if called 


The self address number “SA#” index is included for clarity. Indexes may be useful for efficient memory 
management. 

Ifa net address is associated with a self address, the self address should be referred to as a “net member” 
address. 

Addresses and values shown for example only. 

Valid channels are the channels on which this address is planned, or permitted, to be used. 


A.4.3.3 Other station table. 

The radio shall be capable of storing, retrieving, and employing at least 100 different sets of 
information concerning the addresses of other stations and nets, channel quality data to those 
stations and nets (measurements or predictions), and equipment settings specific to links with 
each station or net. 


DO: any excess capacity which is not programmed with preplanned other station information 
should be automatically filled with any addresses heard on any of the scanned or monitored 
channels. When the excess capacity is filled, it should be kept current by replacing the oldest 
heard addresses with the latest ones heard. This information should be used for call initiation to 
stations (if needed), and for activity evaluation. 


A.4.3.3.1 Other station address storage. 
Individual station addresses shall be stored in distinct table entries, and shall be associated with a 


specific wait for reply time (Tyr) if not the default value. Net information shall include own net 
and net member associations, relative slot sequences, and own net wait for reply times (Twn) for 
use when calling. See figure A-4. The storage for addresses and settings shall be nonvolatile. 
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FIGURE A-4. Connect 
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A.4.3.3.2 Link quality memory. 

The equipment shall be capable of storing, retrieving, and employing at least 4000 (DO: 10,000) 
sets of connectivity and LQA information associated with the channels and the other addresses in 
an LQA memory. The connectivity and LQA information storage shall be retained in memory 
for not less than one hour during power down or loss of primary power. The information in each 
address/channel “cell” shall include as a minimum, bilateral SINAD values of (a) the signals 
received at the station, and (b) the station’s signals received at, and reported by, the other station. 
It shall also include either an indicator of the age of the information (for discounting old data), or 
an algorithm for automatically reducing the weight of data with time, to compensate for changing 
propagation conditions. (DO: the cells of the LQA memory should also include bilateral bit-error 
ratio (BER) and bilateral MP information derived by suitably equipped units.) The information 
within the LQA memory shall be used to select channels and manage networks as stated in this 
document. See figure A-4. 


A.4.3.3.3 Other station settings storage. 

DO: Equipment settings for use in linking with specific stations or nets should be stored in 
nonvolatile memory. Such settings may include antenna selection and azimuth, channels 
authorized for that station or net, power limits for the relevant net, and so on. 


A.4.3.4 Operating parameters. 
The following ALE operating parameters shall be programmable by the operator or an external 
automated controller. Complete definitions of the parameters are provided in Appendix H. 


ScanRate RequestLQA OtherAddr LgaStatus 
MaxScanChan AutoPowerAdj OtherAddrStatus LqaAge 
MaxTuneTime SelfAddrTable OtherAddrNetMembers | LqaMultipath 
TurnAroundTime SelfAddrEntry OtherAddrValidChannels | LqaSINAD 
ActivityTimeout SelfAddr OtherAddrAnt LqaBER 
ListenTime SelfAddrStatus OtherAddrAntAzimuth ScanSet 
AcceptAnyCall NetAddr OtherAddrPower ConnectionTable 
AcceptAllcall SlotWaitTime LqaMatrix ConnectionEntry 
AcceptAMD SelfAddrValidChannels | LqaEntry ConnectedAddr 
AcceptDTM OtherAddrTable LqaAddr ConnectionStatus 
AcceptDBM OtherAddrEntry LgaChannel 


A.4.3.5 Message memory. 

Storage for preprogrammed, operator entered, and incoming messages shall be provided in the 
equipment. This storage shall be retained in memory for not less than one hour during power 

down or loss of primary power. Storage for at least 12 messages (DO: 100 messages), and a 

total capacity of at least 1000 characters (DO: 10,000 characters) shall be provided. 
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A.4.4 ALE operational rules. 

The ALE system shall incorporate the basic operational rules listed in table A-V. Some of these 
rules may not be applicable in certain applications. For example, “always listening” is not 
possible while transmitting with a transceiver or when using a common antenna with a separate 
transmitter and receiver. 


TABLE A-V. ALE operational rules. 


5) Will not interfere with active channel carrying detectable traffic in accordance with table A-I (unless this 
listen call function is overriden by the operator or other controller). 


6) Always will exchange LQA with other stations when requested (unless inhibited), and always measures the 
signal quality of others 


7) Will respond in the appropriate time slot to calls requiring slotted responses 


9) Linking ALE stations employ highest mutual level of capability. 
10) Minimize transmit and receive time on channel 
11) Automatically minimize power used (if capable) 


NOTE : Listed in order of precedence. 


8) Always seek (unless inhibited) and maintain track of their connectivities with others. 


A.4.5 Alternate Quick Call ALE (AQC-ALE) (NT). 


A.4.5.1 Introduction. 

This feature may be implemented in addition to the basic ALE functionality described in this 
appendix. The AQC-ALE provides a link establishment technique that requires significantly less 
time to link than the baseline ALE system. This is accomplished by some additional technology 
and trading-off some of the lesser used functions of the baseline system, for a faster linking 
process. The AQC-ALE shall always be listening for the baseline ALE call and shall 
automatically respond and operate in that mode when called. 


A.4.5.2 General signaling strategies. 
The AQC-ALE format employs the following characteristics: 


a. Packs three address characters (21 bits) into a 16-bit value 
b. Addresses are reduced from a maximum of 15 characters to 6 characters 
c. Six (6) address characters are sent in every transaction 


d. Replaces two seldom used preambles as follows: 
e FROM preamble becomes PART2 indicating the 2nd address word 
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e THRU preamble becomes INLINK indicating a linked transaction 


e. Isolates station addresses from message portion of the signaling structure: 


e CMD, DATA, and REP are used for messaging 


f. Easy separation of second generation basic ALE and AQC-ALE protocols: 


e Fixes | bit of any address word 


e Prevents legitimate addresses in AQC-ALE from being legitimate addresses in second 
generation basic ALE. 


g. Provides at least eight information bits per transmission 


A.4.5.3 Features supported by AQC-ALE. 
The following basic ALE features are fully implemented using the AQC-ALE protocol. 


NOTE: A station operating in AQC-ALE can respond to any call type, but a station equipped 
with only second generation basic ALE will not respond to AQC-ALE protocol forms. 


a. 
b. 


Cc. 


Linking protection levels 0, 1, 2, 3 
Unit calls 


Star Net calls 


. Allcalls 
. AnyCalls 


LQA Exchange as part of the call handshake 


. Supports Orderwire and Relay features while in a link: 


e automatic message display (AMD), data text message (DTM) or DBM 
e User Unique Functions (UUF) when in a link 
e Call Relay features 


e Time of day and Network Management 


. Sound: 


e Sounds are shortened to include scan time + 50percent 


e Sounds may include a PSK signal to enhance LQA data 
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A.4.5.4 Features not provided by AQC-ALE. 


a. Group call. As an alternative, a controller can use the calling protocol to add on additional 
members. Behavior of the system is more akin to setting up a call and then conferencing in a 
third party. 


b. AMD, DTM, DBM are not provided during link set up. Primary focus of AQC-ALE is to 
establish a link between two or more stations as rapidly as possible. Once linked, information 
can be exchanged in the most efficient manner as is common between stations. 


c. Early identification of transmitter’s address during orderwire traffic or additional 
addressing identification for relay addresses. The need for this is eliminated because the call 
setup is significantly reduced. Orderwire messages are not allowed during the call setup. 


A.5. DETAILED REQUIREMENTS. 


A.5.1 ALE modem waveform. 


A.5.1.1 Introduction. 

The ALE waveform is designed to pass through the audio passband of standard SSB radio 
equipment. This waveform shall provide for a robust, low-speed, digital modem capability used 
for multiple purposes to include selective calling and data transmission. This section defines the 
waveform including the tones, their meanings, the timing and rates, and their accuracy. 


A.5.1.2 Tones. 

The waveform shall be an 8-ary frequency shift-keying (FSK) modulation with eight orthogonal 
tones, one tone (or symbol) at a time. Each tone shall represent three bits of data as follows 
(least significant bit (LSB) to the right): 


e 750 Hz 000 
e 1000 Hz 001 
e 1250 Hz O11 
e 1500 Hz 010 
e 1750 Hz 110 
e 2000 Hz 111 
e 2250 Hz 101 
e 2500 Hz 100 


The transmitted bits shall be encoded and interleaved data bits constituting a word, as described 
in paragraphs A.5.2.2 and A.5.2.3. The transitions between tones shall be phase continuous and 
shall be at waveform maxima or minima (slope zero). 


66 


MIL-STD-188-141B 
APPENDIX A 


A.5.1.3 Timing. 

The tones shall be transmitted at a rate of 125 tones (symbols) per second, with a resultant period 
of 8 ms per tone. Figure A-5 shows the frequency and time relationships. The transmitted bit 
rate shall be 375 bits per second (b/s). The transitions between adjacent redundant (tripled) 
transmitted words shall coincide with the transitions between tones, resulting in an integral 

49 symbols (or tones) per redundant (tripled) word. The resultant single word period (Ty) shall 
be 130.66... ms (or 16.33... symbols), and the triple word (basic redundant format) period (3 T,,) 
shall be 392 ms. 


A.5.1.4 Accuracy. 

At baseband audio, the generated tones shall be within +1.0 Hz. At rf, all transmitted tones shall 
be within the range of 2.0 dB in amplitude. Transmitted symbol timing, and therefore, the bit 
and word rates shall be within ten parts per million. 
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SNONNILNOO ASVHd 
dd TIVHS SNOILISNVYL IOEWAS -3LON 


(SdS SZL) 
JOSWAS/GOlYad 


(SdS SZL) 
JOSEWAS/SATIOAD 
S1Igd VLVG 


2H OSZ 


2H 0001 
ZH OSL 
2H OOS/ 


ZH OSLL 
2H 0002 


2H 0S2¢ 


2H 00S 


AONANDAYSA 


FIGURE A-5. ALE symbol library. 
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A.5.2 Signal structure. 


A.5.2.1 Introduction. 

This section provides definition of the ALE signal structure. Included are: forward error 
correction, word structure, addressing, frame structure, and synchronization. Also described in 
this section are: addressing, signal quality analysis, and the functions of the standard word 
preambles associated with the signal structure. 


A.5.2.2 FEC. 


A.5.2.2.1 General. 

The effective performance of stations, while communicating over adverse rf channels, relies on 
the combined use of forward error correction, interleaving, and redundancy. These functions 
shall be performed within the transmit encoder and receive decoder. 


A.5.2.2.2 Golay coding. 
The Golay (24, 12, 3) FEC code is prescribed for this standard. The FEC code generator 
polynomial shall be: 


g(x)=x +x°+x) +x°t¢x°+¢x41 


The generator matrix G, derived from g(x), shall contain an identity matrix I)2 and a parity matrix 
P as shown in figure A-6. The corresponding parity check matrix H shall contain a transposed 
matrix p' and an identity matrix I) as shown in figure A-7. 


A.5.2.2.2.1 Encoding. 

Encoding shall use the fundamental formula x = uG, where the code word x shall be derived 
from the data word u and the generator matrix G. Encoding is performed using the G matrix by 
summing (modulo-2) the rows of G for which the corresponding information bit is a “1.” See 
figures A-6, A-8, and A-9a. 


A.5.2.2.2.2 Decoding. 
Decoding will implement the equation 

s=y H' 
where y = x + e is a received vector which is the modulo-2 sum of a code word x and an error 
vector e, s is a vector of “n - k” bits called the syndrome. See figure A-9. See figure A-7 for the 
value of H. Each correctable/detectable error vector e results in a unique vector s. Because of 
this, s is computed according to the equation above and is used to index a look-up of the 
corresponding e, which is then added modulo-2 to y to give the original code word x. Flags are 
set according to the number of errors being corrected. The uses of the flags are described in 
A.5.2.6. Ifs is not equal to 0 and e contains more ones than the number of errors being corrected 
by decoding mode, a detected error is indicated and the appropriate flag is set. 
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FIGURE A-6. Generator matrix for (24, 12) extended Golay code. 
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FIGURE A-7. Parity-check matrix for (24, 12) extended Golay code. 
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12 Bits To Encode 


ZOR MH wRaPZ CG 


nAmMmnEecz 


ENCODED DATA BITS* GOLAY CHECK BITS 
W,...Wi2 (OR Wj3...W22) G,...Gi2 (OR 
Gj3...Gr4) 
24 BITS CODE WORD TO SEND 


*See note 2 


NOTES: 
1. The “bits” to be encoded determine which rows of the “G” generator matrix are to be 
“modulo-2” summed. In this example, bits 1, 2, 4, 8, 10, and 12 are “1,” so row 1, 2, 4, 8, 
10, and 12 are summed. 


2. Because this is a “systematic” code, the original 12 data bits also appear in the output 
encoded 24 bits. 


FIGURE A-8. Golay word encoding example. 
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12 INPUT DATA BITS “W” 12 GOLAY CHECK BITS “G” 


GOLAY ENCODE ROM 


4K X12 BITS 
(NOTE 1) 


24 OUTPUT FEC BITS TRANSMITTED 


a. GOLAY FEC ENCODING EXAMPLE 


24 INPUT FEC BITS RECEIVED (WITH ERRORS) 


RECEIVED W,. . W RECEIVED G. . Gy 
(PLUS ERRORS) (PLUS ERRORS) 


SAME GOLAY 


ENCODE ROM ENCODE ROM 


ADDRESS 
W,. . Wyo SAME 
(PLUS ERRORS) 4K X12 BITS e G 12-BIT 
1: 12 “EXCLUSIVE OR’ 
NCTE?) (PLUS ERRORS) 


GOLAY DECODE ROM 
DATA BITS 


EROSIVE OS PATTERN (NOTE 1) “SYNDROME” USED AS 


TO CORRECT ADDRESS POINTER BASED 
ON “G” ERROR PATTERN 


Ww, W, Ws . ¥ Wy Wi 
~CORRECTED DATA BITS ‘W” 


b. GOLAY FEC DECODING EXAMPLE 


NOTES: 


1, ENCODE ROM CONTAINS GOLAY CHECK BITS “G,. G ,.” AT EACH ADDRESS, BASED ON DATA BITS 
“W,. . Wyo” PREVIOUSLY COMPUTED FROM GENERATOR MATRIX “G” AND STORED. 


2. DECODE ROM MAY INCLUDE ADDITIONAL BITS (OVER THE BASIC 12 TO CORRECT “W” BITS) TO INDICATE 
QUANTITY OR DATA ERRORS DETECTED AND CORRECTABILITY. 


3. ROM “LOOK UP” HARDWARE FOR EXAMPLE ONLY. SOFTWARE IMPLEMENTATIONS MAY BE PREFERRED. 


FIGURE A-9. Golay FEC coding examples. 


A.5.2.2.3 Interleaving and deinterleaving. 

The basic word bits W1 (most significant bit (MSB)) through W24 (LSB), and resultant Golay 
FEC bits G1 through G24 (with G13 through G24 inverted), shall be interleaved, before 
transmission using the pattern shown in figure A-10. The 48 interleaved bits plus a 49th stuff bit 
S49, (value = 0) shall constitute a transmitted word and they shall be transmitted Al, B1, A2, 
B2... A24, B24, S49 using 16-1/3 symbols (tones) per word (T,,) as described in A.5.1.3. At the 
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receiver, and after 2/3 voting (see A.5.2.2.4), the first 48 received bits of the majority word 
(including remaining errors) shall be deinterleaved as shown in figure A-10 and then Golay FEC 
decoded to produce a correct(ed) 24-bit basic word (or an uncorrected error flag). The 49th stuff 
bit (S49) is ignored. 


A.5.2.2.4 Redundant words. 
Each of the transmitted 49-bit (or 16-1/3 symbol) (T,,) words shall be sent redundantly (times 3) 
to reduce the effects of fading, interference, and noise. An individual (or net) routing word 
(TO...), used for calling a scanning (multichannel) station (or net), shall be sent redundantly as 
long as required in the scan call (Ts-) to ensure receipt, as described in A.5.5.2. However, when 
the call is a non-net call to multiple scanning stations (a group call, using THRU and REPEAT 
(REP) alternately), the first individual routing word (THRU) and all the subsequent individual 
routing words (REP, THRU, REP....) shall be sent three adjacent times (T;,). These triple words 
for the individual stations shall be rotated in group sequence as described in A.5.5.3. See figure 
A-11. At bit time intervals (approximately T,,/49), the receiver shall examine the present bit and 
past bit stream and perform a 2/3 majority vote, on a bit-by-bit basis, over a span of three words. 
See tables A-VI and A-VII. The resultant 48 (ignoring the 49th bit) most recent majority bits 
constitute the latest majority word and shall be delivered to the deinterleaver and FEC decoder. 
In addition, the number of unanimous votes of the 48 possible votes associated with this majority 
word are temporarily retained for use as described in A.5.2.6. 


A.5.2.3 Word structures. 


A.5.2.3.1 ALE word format. 
The basic ALE word shall consist of 24 bits of information, designated W1 (MSB) through W24 
(LSB). The bits shall be designated as shown in figure A-12. 
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CODER B DECODER B 


G24 B24 

623g B23 LAST BITS 

G22 a B22 49th STUFF BIT =0 
G21 BS B21 
G20 &% B20 
Gig 2% B19 
G18 wiz B18 
Gi7 az B17 
G16 Sz B16 
Gis FS B15 
Gt4 
G13 


O! 


CHECK BITS INVERTED 
TER EN 
CHECK BITS REINVERTED 
TO NORMAL BEFORE DECODING 


OM NORM, 


Ww24 


EAEPEA- 


— 
— 
— =s 
——S>SS=S=_ 
CHARACTER 3 


CHARACTER 3 
EEE 
== 


== 


Ah 
\ \) 


CHECK BITS NORMAL 
CHECK BITS NORMAL 
CHARACTER 1 CHARACTER 2 


CHARACTER 1 


PREAMBLE 
PREAMBLE 


BITS SENT FIRST 


INPUT BASIC GOLAY ENCODING INTER- TRANSMITTED _DEINTER- GOLAY DECODING OUTPUT BASIC 
WORD (24 BITS) LEAVING WORDS LEAVING WORD (24 BITS) 
(49 BITS) 


FIGURE A-10. Word bit coding and interleaving. 
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“AOVSSAW LXAL VLVd OL SY3s5u 


GWV -AV1dSIG JOVSSAW OILVNOLNV OL SHY3SSY ‘JOVSSAW YOOTE VLVG OL SYS435Y 
“SAWIL LNAOVPQV SSYHL LSVATLV GSLLINSNVYL 48 OL W GYOM HOVA SSYINDAY ONILOA €/2 40 ASN *b 


‘SALON 


(wad) (WLO ‘WY ‘31v) 


ONIGOOAC GNV ONIGODSC GNV 
ONIAVATYSLNISG ONIAVATYSLNISG 
GSLNAIYO LI G3LN3l¥O GHOM 


| 
Sila W GYOM W GYOM 
FIONIS FIONIS ALIYOrVIN 


Y¥dd003d ALOA 


ALIMOPVWN €/2 
GSLNAIYO Lid 


MO14 (LI) GHOM 


N 
te .}4W GYOM, LNVONNGSY 2 — WGYOM, LNVONNGSy 


_., TWO ONIGVAT ye TIVO NVOS TIVO TWACIAICNI 


FIGURE A-11. Bit and word decoding. 
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TABLE A-VI. 2/3 Majority vote decoding. 


Eight Possible Bit Combinations 
Received Bit R Received Time 


R (an) (now) a NT 
R(n-49) (Ty old) 113066.ms [oo |i [1 [o [o |i (1 | 
R(n-98) 2, old) prasiss.ms fo foe Pr fo fr fof 
Resultant majoritybaM: Si CS 


Possible error flag: 
0 = error unlikely 
1 = error likely 


Majority Used as Decoder 
Relative Time Received Bits R. (Time) for 2/3 Voting Words Bit M Bits 


Stuff bits - R(m-98) S49 ignored 

Recent (LSB) - - R(n-99) - B24 (LSB) 
R(n-100) - A24 
R(n-101) - B23 
R(n-102) - A23 


R(n-46) R(n-95) R(n-144) M(n-46) 
R(n-47) R(n-96) R(n-145) M(n-47) 
Older (MSB) R(n-48) R(n-97) R(n-146) M(n-48) 


NOTES: 
1. “n” indicates present bit time 
2. “n-m” indicates bit received at ““m’” bit times earlier 
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7 BITS 


CHARACTER 3 
(TRAILING) 
ere kas aR Ss Sm Ga On 


GOLAY CODEC B 


CHARACTER 2 
(MIDDLE) 
7 BITS 

oy acy Mio Um oy ge cy Man Ov ane oF) 


Q 
a 
e) 
= 
Q 
ce 
< 
a 
Zz 
= 
| ond 
7a) 
Lu 
! 
= 


CHARACTER 1 
(LEADING) 
7 BITS 
C1 Et cl 


24 BITS 
C1 C 
GOLAY CODEC A — 


1. THREE 7-BIT ASCII CHARACTERS PER WORD IN DATA FIELD (W4-W10, W11-W17, W18-W24). 
OPTIONAL 21-BIT UNFORMATTED DATA FIELD (W4-W24). MSB (W1) TRANSMITTED FIRST. 


PREAMBLE 
3 BITS 
NOTE: 


FIGURE A-12. ALE basic word structure. 


A.5.2.3.1.1 Structure. 

The word shall be divided into two parts: a 3-bit preamble and a 21-bit data field (which often 
contains three 7-bit characters). The MSB for all parts, and the word, is to the left in figure A-12 
and is sent earliest. Before transmission, the word shall be divided into two 12-bit halves (Golay 
code A and B in figure A-10) for FEC encoding as described in 5.2.2. 
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The optional AQC-ALE word packs the address data. Details of this can be found in A.5.8.1.1, 
AQC-ALE Address Word Structure. 


A.5.2.3.1.2 Word types. 
The leading three bits, W1 through W3, are designated preamble bits P3 through P1, respectively. 
These preamble bits shall be used to identify one of eight possible word types. 


A.5.2.3.1.3. Preambles. 
The word types (and preambles) shall be as shown in table A-VIII and as described herein. 


Optional AQC-ALE preambles are defined in A.5.8.1.2. 


TABLE A-VIII. ALE word types (preambles). 


Code Bits Functions Significance 


multiple (and indirect present multiple direct destinations for group calls 
routing (and future indirect relays, reserved) 

direct routing present direct destination for individual and net calls 
orderwire control and ALE system-wide station (and operator) orderwire for 
status coordination, control, status, and special functions 
identification (and identification of present transmitter without 

indirect routing) termination (and past originator and relayers, reserved) 
terminator and identification of present transmitter, signal 
identification terminations, protocol continuation 

continuing 


terminator and identification of present transmitter, signal and 
identification quitting protocol termination 

extension and extension of data field of the previous ALE work, or 
information information defined by the previous CMD 
duplication and duplication of the previous preamble, or information 
information defined by the previous CMD 


A.5.2.3.2 Address words. 


A.5.2.3.2.1 TO. 

The TO word (010) shall be used as a routing designator which shall indicate the address of the 
present destination station(s) which is (are) to directly receive the call. TO shall be used in the 
individual call protocols for single stations and in the net call protocols for multiple net-member 
stations which are called using a single net address. The TO word itself shall contain the first 
three characters of an address. For extended addresses, the additional address words (and 
characters) shall be contained in alternating DATA and REP words, which shall immediately 
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follow. The sequence shall be TO, DATA, REP, DATA, and REP, and shall be only long enough 
to contain the address, up to a maximum capacity of five address words (15 characters). 


A.5.2.3.2.2 THIS IS (TIS). 
The TIS word (101) shall be used as a routing designator which shall indicate the address of the 


present calling (or sounding) station which is directly transmitting the call (or sound). Except for 
the use of TWAS, TIS shall be used in all ALE protocols to terminate the ALE frame and 
transmission. It shall indicate the continuation of the protocol or handshake, and shall direct, 
request, or invite (depending on the specific protocol) responses or acknowledgments from other 
called or receiving stations. The TIS shall be used to designate the call acceptance sound. The 
TIS word itself shall contain the first three characters of the calling stations address. For 
extended addresses, the additional address words (and characters) shall be contained in 
alternating DATA and REP words which shall immediately follow, exactly as described for 
whole addresses using the TO word and sequence. The entire address (and the required portion 
of the TIS, DATA, REP, DATA, REP sequence, as necessary) shall be used only in the 
conclusion section of the ALE frame (or shall constitute an entire sound). TWAS shall not be 
used in the same frame as TIS, as they are mutually exclusive. 


A.5.2.3.2.3. THIS WAS (TWAS). 

The TWAS word (011) shall be used as a routing designator exactly as the TIS, with the 
following variations. It shall indicate the termination of the ALE protocol or handshake, and 
shall reject, discourage, or not invite (depending on the specific protocol) responses or 
acknowledgments from other called or receiving stations. The TWAS shall be used to designate 
the call rejection sound. TIS shall not be used in the same frame as TWAS, as they are mutually 
exclusive. 


A.5.2.3.2.4 THRU. 

The THRU word (001) shall be used in the scanning call section of the calling cycle only with 
group call protocols. The THRU word shall be used alternately with REP, as routing 
designators, to indicate the address first word of stations that are to be directly called. Each 
address first word shall be limited to one basic address word (three characters) in length. A 
maximum of five different address first words shall be permitted in a group call. The sequence 
shall only be alternations of THRU, REP. The THRU shall not be used for extended addresses, 
as it will not be used within the leading call section of the calling cycle. When the leading call 
starts in the group call, the entire group of called stations shall be called with their whole 
addresses, which shall be sent using the TO preambles and structures, as described in A.5.2.3.2.1. 


NOTE: 1. The THRU word is also reserved for future implementation of indirect and relay 
protocols, in which cases it may be used elsewhere in the ALE frame and with whole 
addresses and other information. Stations designed in compliance with this nonrelay 
standard should ignore calls to them which employ their address in a THRU word in other 
than the scanning call. 
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NOTE: 2. The THRU preamble value is also reserved for the AQC-ALE protocol. 


A.5.2.3.2.5 FROM. 

The FROM word (100) is an optional designator which shall be used to identify the transmitting 
station without using an ALE frame termination, such as TIS or TWAS. It shall contain the 
whole address of the transmitting station, using the FROM, and if required, the DATA and REP 
words, exactly as described in the TO address structure in A.5.2.3.2.1. It should be used only 
once in each ALE frame, and it shall be used only immediately preceding a command (CMD) in 
the message section. Under direction of the operator or controller, it should be used to provide a 
“quick ID” of the transmitting station when the normal conclusion may be delayed, such as when 
a long message section is to be used in an ALE frame. 


NOTE: 1. The FROM word is also reserved for future implementation of indirect and relay 
protocols, in which cases it may be used elsewhere in the ALE frame and with multiple 
addresses and other information. Stations designed in compliance with this nonrelay 
standard should ignore sections of calls to them that employ FROM words in any other 
sequence than immediately before the CMD word. 


NOTE: 2. The FROM preamble value is also reserved for the AQC-ALE protocol. 


A.5.2.3.3 Message words. 
All message words (orderwire messages) begin with a word with the CMD preamble. 


A.5.2.3.3.1 CMD. 

The CMD word (110) is a special orderwire designator which shall be used for system-wide 
coordination, command, control, status, information, interoperation, and other special purposes. 
CMD shall be used in any combination between ALE stations and operators. CMD is an optional 
designator which is used only within the message section of the ALE frame, and it shall have (at 
some time in the frame) a preceding call and a following conclusion, to ensure designation of the 
intended receivers and identification of the sender. The first CMD terminates the calling cycle 
and indicates the start of the message section of the ALE frame. The orderwire functions are 
directed with the CMD itself, or when combined with the REP and DATA words. See A.5.6 for 
message words (orderwire messages) and functions. 


A.5.2.3.4 Extension words. 


A.5.2.3.4.1 DATA. 

The DATA word (000) is a special designator which shall be used to extend the data field of any 
previous word type (except DATA itself) or to convey information in a message. When used 
with the routing designators TO, FROM, TIS, or TWAS, DATA shall perform address extension 
from the basic three characters to six, nine, or more (in multiples of three) when alternated with 
REP words. The selected limit for address extension 1s a total of 15 characters. When used with 


81 


MIL-STD-188-141B 
APPENDIX A 


CMD, its function is predefined as specified in A.5.6 for message words (orderwire messages) 
and functions. 


A.5.2.3.4.2 REP. 

The REP word (111) is a special designator which shall be used to duplicate any previous 
preamble function or word meaning while changing the data field contents (bits W4 through 
W24). See table A-VIII. Any change of words or data field bits requires a change of preamble 
bits (P3 through P;) to preclude uncertainty and errors. Ifa word is to change, even if the data 
field is identical to that in the previous word, the preamble shall be changed, thereby clearly 
designating a word change. When used with the routing designator TO, REP performs address 
expansion, which enables more than one address to be specified. See A.5.2.3.2.4 for use with 
THRU. With DATA, REP may be used to extend and expand address, message, command, and 
status fields. REP shall be used to perform these functions, and it may directly follow any other 
word type except for itself, and except for TIS or TWAS, as there cannot be more than one 
transmitter for a specific call at a given time. 


NOTE 1. REP is used in T,, of group calls directed to units with different first word 
addresses. 


NOTE 2. REP is not used in Ty of calls directed to groups with same first word addresses. 
Also REP is not used in Ts. of calls directed to individuals and nets. 


A.5.2.4 Addressing. 


A.5.2.4.1 Introduction. 

The ALE system deploys a digital addressing structure based upon the standard 24-bit (three 
character) word and the Basic 38 character subset. As described below, ALE stations have the 
capability and flexibility to link or network with one or many prearranged or as-needed single or 
multiple stations. All ALE stations shall have the capacity to store and use at least 20 self 
addresses of up to 15 characters each in any combination of individual and net calls. There are 
three basic addressing methods which will be presented: 


e Individual station 
e Multiple station 


e Special modes 


NOTE: Certain alphanumeric address combinations may be interpreted to have special 
meanings for emergency or specific functions, such as “SOS,” “MAYDAY,” “PANPAN,” 
“SECURITY,” “ALL,” “ANY,” and “NULL.” These should be carefully controlled or 
restricted. 
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A.5.2.4.2 Basic 38 ASCII subset. 

The Basic 38 ASCII subset shall include all capital alphabetics (A-Z) and all digits (0-9), plus 
designated utility and wildcard symbols “@” and “?,” as shown in figure A-13. The Basic 38 
ASCII subset shall be used for all basic addressing functions. To be a valid basic address, the 
word shall contain a routing preamble from A.5.2.3.2 (such as TO...), plus three alphanumeric 
characters (A-Z, 0-9) from the Basic 38 ASCII subset in any combination. In addition, the “@” 
and ““?” symbols shall be used for special functions. Digital discrimination of the Basic 38 
ASCII subset shall not be limited to examination of only the three MSBs (b7 through bs), as a 
total of 48 digital bit combinations would be possible (including ten invalid symbols which 
would be improperly accepted). 


OL, eo] nt DA] mI BY] WT] KI] KH | CO] Ww 


>} —| —| =] N| KX] &] =] <] GC] A] @] A] OC] eI] u 


ePepelelelrelelRel ol cof of of of co] of of/<€ Ff 
Belelelelol of ol of KH] KH] Kl Kl ol of of of/€o 


OO} Z| Z| rl] A] a] Se] oe] Ol] a] ma] Oo] a] wm] >] eA 


co) 


FIGURE A-13. Basic 38 ASCII subset (unshaded areas). 


A.5.2.4.3 Stuffing. 

The ALE basic address structure is based on single words which, in themselves, provide 
multiples of three characters. The quantity of available addresses within the system, and the 
flexibility of assigning addresses, are significantly increased by the use of address character 
stuffing. This technique allows address lengths that are not multiples of three to be compatibly 
contained in the standard (multiple of three characters) address fields by “stuffing” the empty 
trailing positions with the utility symbol “@.” See table A-IX. “Stuff-1” and “Stuff-2” words 
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shall only be used in the last word of an address, and therefore should appear only in the leading 
call (T\.) of the calling cycle (T¢c). 


NOTE: As an example of proper usage, a call to the address “MIAMI” would be structured 
“TO MIA,” “DATA MI@.” 


A.5.2.4.4 Individual addresses. 

The fundamental address element in the ALE system is the single routing word, containing three 
characters, which forms the basic individual station address. This basic address word, used 
primarily for intranet and slotted operations, may be extended to multiple words and modified to 
provide increased address capacity and flexibility for internet and general use. An address which 
is assigned to a single station (within the known or used network) shall be termed an “individual” 
address. If it consists of one word (that is, no longer than three characters) it shall be termed a 
“basic” size, and if it exceeds one word, it shall be termed an “extended” size. 
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TABLE A-IX. Use of “@” utility symbol. 


Function 


“Standard” three character address 
structure “ABC” 


“Stuff-1” reduced address fields; adds 
characters “A, B” 


“Stuff-2” reduced address fields; adds 
character “A” 


“Allcall” global address; all stop and 
listen (unless inhibited), none respond 


“Selective AllCall;” global address; all 
with same last character “A” (or “B”’) stop 
and listen (unless inhibited), none respond 


“AnyCall” global address; all stop and 
respond in PRN slots (unless inhibited), 
none respond 


“Selective AnyCall;” all with same last 
character(s) “A” (or “B”) stop and 
respond in PRN slots (unless inhibited), 
using own addresses 


“Double selective AnyCall;” all with 
same last characters “AB” (or “CD”) stop 
and respond in PRN slots (unless 
inhibited), using own addresses 


“Null” address; all ignore, test and 
maintenance use, or extra “buffer” slot 


Guidance 


Any position in address and sequences 


Only last word in address; anywhere in 
sequences 


Only last word in address; anywhere in 
sequences 


Exclusive member of calling cycle; 
single TO only 


Alone, or with additional different 
AllCall selections, for “group selective 
AllCall;” only in calling cycle; must 
use TO, REP alternately never DATA, 
if more than one* 


Exclusive member of calling cycle; 
single TO only 


Alone or with additional different 
AnyCall selections, for “group 
selective AnyCall;” only in calling 
cycle; must use TO, REP alternately 
(never DATA), if more than one* 


Alone or with additional different 
AnyCall selections, for “group 
selective AnyCall;” only in calling 
cycle; must use TO, REP alternately 
(never DATA), if more than one* 


Any position in address sequence 
(omit from T,, if group call) except 
never in conclusion (terminator), or 
REP, only if following TO 


All patterns not shown here are reserved and shall be considered invalid until standardized. 
“@” indicates special utility character (1000000); “?” wildcard (0111111). 
“A.” “B,” “C,” or “D” indicates any alphanumeric member of Basic 38 ASCII subset other than “@,” or 
“2,” that is “A-Z” and “0-9.” 
* THRU, REP in T,, if group call. 
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A.5.2.4.4.1 Basic size. 

The basic address word shall be composed of a routing preamble (TO, or possibly a REP which 
follows a TO, in T\, of group call, or a TIS or TWAS) plus three address characters, all of which 
shall be alphanumeric numbers of the Basic 38 ASCII subset. The three characters in the basic 
individual address provide a Basic 38-address capacity of 46,656, using only the 36 
alphanumerics. This three-character single word is the minimum structure. In addition, all ALE 
stations shall associate specific timing and control information with all own addresses, such as 
prearranged delays for slotted net responses. As described in A.5.5, the basic individual 
addresses of various station(s) may be combined to implement flexible linking and networking. 


NOTE: All ALE stations shall be assigned at least one (DO: several) single-word address 
for automatic use in one-word address protocols, such as slotted (multistation type) 
responses. This is a mandatory user requirement, not a design requirement. However, 
nothing in the design shall preclude using longer addresses. 


A.5.2.4.4.2 Extended size. 

Extended addresses provide address fields which are longer than one word (three characters), up 
to a maximum system limit of five words (15 characters). See table A-X. This 15-character 
capacity enables Integrated Services Digital Network (ISDN) address capability. Specifically, the 
ALE extended address word structure shall be composed of an initial basic address word, such as 
TO or TIS, as described above, plus additional words as necessary to contain the additional 
characters in the sequence DATA, REP, DATA, REP, for a maximum total of five words. All 
address characters shall be the alphanumeric members of the Basic 38 ASCII subset. 


NOTE 1: All ALE stations shall be assigned at least one (DO: several) two-word 
address(es) for general use, plus an additional address(es) containing the station’s assigned 
call sign(s). This is a mandatory user requirement, not a design requirement. However, 
nothing in the design shall preclude using longer addresses. 


NOTE 2: The recommended standard address size for intranet, internet, and general non- 
ISDN use is two words. Any requirement to operate with address sizes larger than six 
characters must be a network management decision. As examples of proper usage, a call to 
“EDWARD” would be “TO EDW,” “DATA ARD,” and a call to “MISSISSIPPI” would be 
“TO MIS,” “DATA SIS,” “REP SIP,” “DATA PI@.” 
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TABLE A-X. Basic (38) address structures. 


Address 
Characters 


Basic + 
Stuff-2 


Basic + 
Stuff-1 


2 Basic 


2 Basic 4 
Stuff-2 


2 Basic 4 
Stuff-1 


3 Basic 


E 
x 
T 
E 
N 
D 
E 
D 


3 Basic + 
Stuff-2 


3 Basic + 
Stuff-1 


4 Basic 


4 Basic 4 
Stuff-2 


4 Basic 4 
Stuff-1 


5 Basic 
(limit) 


NOTES: 
1. Basic : ABC 
2. Stuff-2: A@@ 
3. Stuff-l: AB@ 
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A.5.2.4.5 Net addresses. 

The purpose of a net call is to rapidly and efficiently establish contact with multiple prearranged 
(net) stations (simultaneously if possible) by the use of a single net address, which is an 
additional address assigned to all net members in common. When a net address type function is 
required, a calling ALE station shall use an address structure identical to the individual station 
address, basic or extended as necessary. For each net address at a net member’s station, there 
shall be a response slot identifier, plus a slot width modifier if directed by the specific standard 
protocol. As described in paragraphs A.5.5.3 and A.5.5.4, additional information concerning the 
assigned response slots (and size) must be available, and the mixing of individual, net, and group 
addresses and calls is restricted 


A.5.2.4.6 Group addresses. 

The purpose of a group call is to establish contact with multiple nonprearranged (group) stations 
(simultaneously if possible) rapidly and efficiently by the use of a compact combination of their 
own addresses which are assigned individually. When a group address type function is required, 
a calling ALE station shall use a sequence of the actual individual station addresses of the called 
stations, in the manner directed by the specific standard protocol. A station’s address shall not 
appear more than once in a group calling sequence, except as specifically permitted in the group 
calling protocols described in A.5.5.4. 


NOTE: The group feature is not available in the AQC-ALE protocol. 


A.5.2.4.7 Allcall addresses. 

An “AllCall” is a general broadcast that does not request responses and does not designate any 
specific address. This mechanism is provided for emergencies (“HELP!”’), broadcast data 
exchanges, and propagation and connectivity tracking. The global AllCall address is “@?@.” 
The AllCall protocol is discussed in A.5.5.4.4. As a variation on the AllCall, the calling station 
can organize (or divide) the available but unspecified receiving stations into logical subsets, 
using a selective AllCall address. A selective AllCall is identical in structure, function, and 
protocol to the AllCall except that it specifies the last single character of the addresses of the 
desired subgroup of receiving stations (1/36 of all). By replacing the “?” with an alphanumeric, 
the selective AllCall special address pattern is “TO @A@” (or possibly “THRU @A@” and 
“REP @B@” if more than one subset is desired), where “A” (and “B,” if applicable) in this 
notation represents any of the 36 alphanumerics in the Basic-38 subset. “A” and “B” may 
represent the same or different character from the subset, and specifically indicate which 
character(s) must be last in a station’s address in order to stop scan and listen. 


NOTE: For ACQ-ALE, the Part2 address portion shall contain the same three characters 
used in the TO word of the call. 
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A.5.2.4.8 AnyCalls. 


An “AnyCall” is a general broadcast that requests responses without designating any specific 
addressee(s). It is required for emergencies, reconstitution of systems, and creation of new 
networks. An ALE station may use the AnyCall to generate responses from essentially 
unspecified stations, and it thereby can identify new stations and connectivities. The global 
AnyCall address is “@@?.” The AnyCall protocol is discussed in A.5.5.4.5. If too many 
responses are received to an AnyCall, or if the caller must organize the available but unspecified 
responders into logical subsets, a selective AnyCall protocol is used. The selective AnyCall 
address is identical in structure, function, and protocol to the global AnyCall, except that it 
specifies the last single character of the addresses of the desired subset of receiving station (1/36 
of all). By replacing the “?” with an alphanumeric, the global AnyCall becomes a selective 
AnyCall whose special address pattern is “TO @@A.” If even narrower acceptance and 
response criteria are required, the double selective AnyCall should be used. The double selective 
AnyCall is an operator selected general broadcast which is identical to the selective AnyCall 
described above, except that its special address (using “(@AB” format) specifies the last two 
characters that the desired subset of receiving stations must have to initiate a response. 


NOTE: For ACQ-ALE, the Part2 address portion shall contain the same three characters 
used in the TO word of the call. 


A.5.2.4.9 Wildcards. 

A “wildcard” is a special character that the caller uses to address multiple-station addresses with 
a single-call address. The receivers shall accept the wildcard character as a substitute for any 
alphanumeric in their self addresses in the same position or positions. Therefore, each wildcard 
character shall substitute for any of 36 characters (A to Z, 0 to 9) in the Basic 38-character 
subset. The total lengths of the calling (wildcard) address, and the called addresses shall be the 
same. The special wildcard character shall be “?” (0111111). It shall substitute for any 
alphanumeric in the Basic 38-character subset. It shall substitute for only a single-address 
character position in an address, per wildcard character. See table A-XI for examples of 
acceptable patterns. 
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TABLE A-XI. Use of “?” wildcard symbol. 


ABC BASIC “STANDARD,” 1 CASE EACH 


AB? “STANDARD” “WILD-1,” 36 CASES EACH 
A?? 2B? 22?C_| “STANDARD” “WILD-2,” 1296 CASES EACH 
“STANDARD” “WILD-3,” 46656 CASES EACH 
“STUFF-1,” 1 CASE EACH 

“WILD-1” “STUFF-1,” 36 CASES EACH 
“WILD-2” “STUFF-2,” 1296 CASES EACH 
“STUFF-2,” 1 CASE EACH 

“WILD-1” “STUFF-2,” 36 CASES EACH 


“DOUBLE SELECTIVE ANYCALL,” (“DSA”) 
1/1296 CASES 


“DSA” “WILD-1,” 1/36 CASES 


NOT PERMITTED. USE “SELECTIVE 
ANYCALL” 


NOT PERMITTED. USE “GLOBAL ANYCALL” 
“SELECTIVE ANYCALL” 

“GLOBAL ANYCALL” 

“SELECTIVE ALL CALL” 


“GLOBAL ALL CALL” 


pews 


“IN LINK ADDRESS” 


A.5.2.4.10 Self addresses. 

For self test, maintenance, and other purposes, stations shall be capable of using their own self 
addresses in calls. When a self-addressing type function is required, ALE stations shall use the 
following self-addressing structures and protocols. Any ALE calling structures and protocols 
permissible within this standard, and containing a specifically addressed calling cycle (such as 
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“TO ABC,” but not AllCall or AnyCall), shall be acceptable, except that the station may 
substitute (or add) any one (or several) of its own calling addresses into the calling cycle. 


A.5.2.4.11 Null address. 

For test, maintenance, buffer times, and other purposes, the station shall use a null address that is 
not directed to, accepted by, or responded to by any station. When an ALE station requires a null 
address type function, it shall use the following null address protocol. The null address special 
address pattern shall be “TO @@@,” (or “REP @@@”), if directly after another TO. The null 
address shall only use the TO (or REP), and only in the calling cycle (Tec). Null addresses may 
be mixed with other addresses (group call), in which case they shall appear only in the leading 
call (Tj,), and not in the scanning call (Ts,). Nulls shall never be used in conclusion (terminator) 
(TIS or TWAS). Ifa null address appears in a group call, no station is designated to respond in 
the associated slot; therefore, it remains empty (and may be used as a buffer for tune-ups, or 
overflow from the previous slot’s responder, etc.). 


A.5.2.4.12 In-link address. 

The inlink address feature is used by a system to denote that all members in the established link 
are to act upon the information sent in the frame containing the inlink address. The inlink 
address shall be ‘?@?’. When a radio enters the linked condition with one or more stations, the 
radio shall expand the set of recognized self addresses to include the inlink address (‘?@?’). 
When a frame is transmitted by any member of the link using the inlink address, all members are 
thus addressed publicly and are to use the frame information. Thus, if a linked member sent an 
AMD message, all members would present that message to their user. If the member sent a 
frame terminated with a TWAS preamble, then all members would note that the transmitting 
station just ‘left’ the link. Short messages of ‘to-F?@?, to-?@?, tis-TALKINGMEMBER’ would 
act as a keep-alive function and cause the receiving radio to extend any link termination timer. 


A.5.2.5 Frame structure. 

All ALE transmissions are based on the tones, timing, bit, and word structures described in 
paragraphs A.5.1 and A.5.2.3. All calls shall be composed of a “frame,” which shall be 
constructed of contiguous redundant words in valid sequence(s) as described in figure A-14, as 
limited in table A-VII, and in formats as described in A.5.5. There are three basic frame 
sections: calling cycle, message, and conclusion. See A.5.2.5.5 for basic frame structure 
examples. 
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CONCLUSION 
SECTION 
(SEE FIGURE A-18c.) 


MESSAGE 


MESSAGE SECTION 
(SEE FIGURE A-18b.) 


2 
je) 
= 
7 
ns 
Wx 
oH 
>= 
of 
lu 
Oa 
3 
_ 
<x 
Oo 


FIGURE A-14. Valid word sequences. 
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A.5.2.5.1 Calling cycle. 
The initial section of all frames (except sounds) is termed a calling cycle (Tc), and it is divided 


into two parts: a scanning call (Ts:) and a leading call (T),). The scanning call shall be composed 
of TO words if an individual or net call (or THRU and REP words, alternating, if a group call), 
which contain only the first word(s) of the called station(s) or net address. The leading call shall 
be composed of TO (and possibly DATA and REP) words containing the whole address(es) for 
the called station(s), from initiation of the leading call until the start of the message section or the 
conclusion (thus the end of the calling cycle). See figure A-15. The use of REP and DATA is 
described in A.5.2.4. The set of different address first words (T,1) may be repeated as necessary 
for scanning calling (Ts:), to exceed the scan period (T;). There is no unique “flag word” or 
“sync word” for frame synchronization (as discussed below). Therefore, stations may acquire 
and begin to read an ALE signal at any point after the start. The transmitter shall have reached at 
least 90 percent of the selected rf power within 2.5 ms of the first tone transmission following 
call initiation. The end of the calling cycle may be indicated by the start of the optional quick-ID, 
which occupies the first words in the message section, after the leading call and before the start 
of the rest of the message (or conclusion, if no message) section. 


NOTE |: The frame time may need to be delayed (equipment manufacturer dependent) to 
avoid loss of the leading words if the transmitter attack time is significantly long. 
Alternatively, the modem may transmit repeated duplicates of the scanning cycle (set of) first 
word(s) to be sent (not to be counted in the frame) as the transmitter rises to full power (and 
may even use the ALE signal momentarily instead of a tuning tone for the tuner), and then 
start the frame when the power is up. 


NOTE 2: The 2.5-ms permissible delay of the first ALE tone, after the transmitter has 
reached 90 percent of selected power, is in addition to the allowable attack time delay 
specified in 5.3.5.1. 


NOTE 3: Non-compliance with the 90 percent of power parameter will impact the 


probability of linking. Compliance testing for this can be construed to be met if the 
probability of linking criteria is met (see table A-I). 
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GO TO CONCLUSION 
(TERMINATOR) SEQUENCE 


IS THIS A SOUND? FLOWCHART. 


IS THIS A GROUP CALL? IS IT ASCANNING CALL? 
(NO NET CALL?) YES (MULTICHANNEL?) Tq. 
YES 


NO 
CREATE GROUP SCANNING 
CALL (T,,). COLLECT HAS LEADING CALL (T,,) SET 
CALLED ADDRESSES 1st OF WHOLE ADDRESS(ES) 
WORDS ONLY. DELETE (T,) BEEN DONE TWICE? 
DUPLICATES. 
REMAINDER 5 MAX. 


IS THERE A SINGLE TERMINATE CALLING CYCLE 


WORD REMAINING? (T¢c). GO TO Waar HAVE ALL WHOLE CALLED 
SEQUENCE FLOW CHART. ADDRESS(ES) (T,) BEEN 


PROCESSED? 
PUT 4st WORD IN THRU, 
NEXT IN REP, NEXT IN THRU NO 
__ ALTERNATE THRU & REP: USE THE TO AT XXX. 
CYCLE THROUGH ‘st 
WORDS, TO END OF 
PLANNED T,,, TO EXCEED 
IS THIS THE 1st FUTURE 


RECEIVERS Tg. 
ADDRESS TO BE SENT? 


SCANNING CALL IS DONE! 
START LEADING CALL T,,. PUT THE 1st THREE Pigs SENT 
CHARACTERS IN XXX. . 


PUT THE ONLY 1st WORD 
PUT THE 1st THREE 


IN THRU, DUPLICATE 
TO END OF T,.. > Tg. CHARACTERS IN REP. 


IS THE ADDRESS GREATER 
CREATE INDIVIDUAL THAN 3 CHARACTERS? 


(OR NET) SCANNING CALL 


(Tgg-). PUT THE ADDRESS 
1st WORD IN TO. DUPLICATE PUT THE 2nd THREE 
TO END OF Ty... > Tg. CHARACTERS IN DATA. 


IS THE ADDRESS GREATER 
THAN 6 CHARACTERS? 


YES 


@) (CONTINUED) 


FIGURE A-15. Calling cycle sequence. 
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PUT THE THIRD THREE 
CHARACTERS IN REP. 


IS THE ADDRESS GREATER 
THAN NINE CHARACTERS? 


| YES 


PUT THE FOURTH THREE 
CHARACTERS IN DATA. 


IS THE ADDRESS GREATER 
THAN TWELVE CHARACTERS? 


| YES 


PUT THE FIFTH THREE 
CHARACTERS IN REP. 


! 


IS THE ADDRESS GREATER 
THAN FIFTEEEN CHARACTERS? NO 


| YES 


INVALID ADDRESS SEQUENCE! 
DELETE THIS ADDRESS. 
RESTART, OR ALERT OPERATOR 
OR CONTROLLER. 


NO 


FIGURE A-15. Calling cycle sequence (continued). 
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A.5.2.5.2 Message section. 

The second and optional section of all frames (except sounds) is termed a “message.” Except for 
the quick-ID, it shall be composed of CMD (and possibly REP and DATA) words from the end of 
the calling cycle until the start of the conclusion (thus the end of the message). The optional 
quick-ID shall be composed of FROM (and possibly REP and DATA) word(s), containing the 
transmitter’s whole address. It shall only be used once at the start of the CMD message section 
sequences. The quick-ID enables prompt transmitter identification and should be used if the 
message section length is a concern. It is never used without a following (CMD...) message(s). 
The message section shall always start with the first CMD (or FROM with later CMD(s)) in the 
call. See figure A-16. The use of REP and DATA is described in A.5.7.3. The message section 
is not repeated within the call (although messages or information itself, within the message 
section, may be). 


For AQC-ALE, the message section in AQC-ALE is available when in a link. The 
acknowledgement leg (third leg) of a call may be used as an inlink entry condition. See 
A.5.8.2.3. 
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FROM CALLING CYCLE 
SEQUENCE FLOWCHART 
ONLY. 


REFER TO STANDARDIZED IS THERE ANY FORM OF 
Mesa oe tN MESSAGE FUNCTION (LQA, 
FORMATS AND PROPER CMD CRC, TEXT...)? : 
MESSAGES. : eae 


GO TO THE CONCLUSION 
TERMINATOR SEQUENCE 
IS THERE A QUICK-ID? (ONLY FLOWCHART. 
ALLOWED IF A MESSAGE 
SECTION IS TO BE SENT.) 


HAVE ALL MESSAGE 
FUNCTIONS (CMDs) BEEN 
PROCESSED? 
PUT TRANSMITTER ADDRESS 
IN FROM (& DATA & REP .. . ) 


START THE NEXT MESSAGE 

FUNCTION. IS THIS THE 1st 

MESSAGE FUNCTION TO BE 
SENT? 


PUT MESSAGE FUNCTION 


CHARACTER OR ERSVIN WAS THE LAST WORD SENT A 
CMD. CMD? 


PUT THE MESSAGE FUNCTION 
(THREE CHARACTERS OR 
TWENTY-ONE BITS) IN REP. 


IS (ARE) ADDITIONAL DATA 
FIELD(S) REQUIRED FOR THIS 
MESSAGE FUNCTION? 


NO 


IS THIS A DBM? 


PUT THE NEXT THREE TEMPORARILY SWITCH TO 
CHARACTERS (OR TWENTY- DEEP INTERLEAVED BIT 
ONE BITS) IN DATA. TRANSMISSION. SET UP 
ENTIRE DATA BLOCK (WHICH 
RESETS T,,, LIMIT). 


FIGURE A-16. Message sequence. 
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HAVE ANY OF THE MAXIMUM 
LIMITS FOR INDIVIDUAL OR 
TOTAL MESSAGE FIELD SIZE 
BEEN EXCEEDED? 


ARE ADDITIONAL DATA FIELDS 
REQUIRED FOR THIS 
MESSAGE FUNCTION? 


PUT THE NEXT THREE 
CHARACTERS (OR TWENTY- 
ONE BITS) IN REP. 


HAVE ANY OF THE MAXIMUM 
LIMITS FOR INDIVIDUAL OR 
TOTAL MESSAGE FIELD SIZE 
BEEN EXCEEDED? 


INVALID MESSAGE 
SEQUENCE(S)! DELETE THIS 
MESSAGE FUNCTION, 
RESTART, OR ALERT 
OPERATOR OR CONTROLLER. 


FIGURE A-16. Message sequence (continued). 


A.5.2.5.3, Conclusion. 

The third section of all frames is termed a “conclusion.” It shall be composed of either TIS or 
TWAS (but not both) (and possibly DATA and REP) words, from the end of the message (or 
calling cycle sections, if no message) until the end of the call. See figure A-17. Sounds and 
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exception shall start immediately with TIS (or TWAS) words as described in A.5.3. REP shall 
not immediately follow TIS or TWAS. Both conclusions and sounds contain the whole address 
of the transmitting station. 


FROM MESSAGE 


FROM CALLING CYCLE SEQUENCE FLOWCHART. 


SEQUENCE FLOWCHART. 


USE ONLY WHOLE 
TRANSMITTER ADDRESS IN 
SOUND. REFER TO 
STANDARDIZATION 
PROTOCOLS & PROPER 
TERMINATOR USAGE. 


ARE RESPONSES REQUESTED 
(OR TIS FORCED)? 


PUT FIRST THREE PUT FIRST THREE 
CHARACTERS IN JIS. CHARACTERS IN TWAS . 


IS THE ADDRESS GREATER 
THAN THREE CHARACTERS? 
YES 


PUT THE SECOND THREE 
CHARACTERS IN DATA. 
IS THE ADDRESS GREATER 
THAN SIX CHARACTERS? 
YES 
PUT THIRD THREE 
CHARACTERS IN REP. 
IS THE ADDRESS GREATER 
THAN NINE CHARACTERS? 
YES 


FIGURE A-17. Conclusion (terminator) sequences. 
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PUT THE FOURTH THREE 
CHARACTERS IN DATA. 


IS THE ADDRESS GREATER 
THAN TWELVE CHARACTERS? 
YES 


PUT THE FIFTH THREE 
CHARACTERS IN REP. 


IS THE ADDRESS GREATER 
THAN FIFTEEN CHARACTERS? 


YES 


INVALID ADDRESS 
SEQUENCE! DELETE THIS 
ADDRESS. RESTART, OR 

ALERT OPERATOR OR 
CONTROLLER. 


BASIC FRAME |S 
CONSTRUCTED. TRIPLE EACH 
WORD FOR REDUNDANCY, 
EXCEPT THE DBM DATA 
BLOCK ITSELF. THE SCAN 
CALL HAS BEEN MULTIPLIED 
TO EXCEED SCAN PERIOD OF 
RECEIVER. LEADING CALL 
HAS BEEN DOUBLED. OTHER 
ALE WORDS JUST TRIPLED 
ONCE. SEND IT! 


BASIC FRAME IS 
CONSTRUCTED. TRIPLE EACH 


ae HA eam a HAS THE PLANNED SCANNING 
REDUNDANT SOUND (T, 


) 
SOUND (T,.,) HAS BEEN BEEN FILLED? 


MULTIPLIED TO EXCEED SCAN 
REPEAT THE SOUNDED 
ADDRESS? 


PERIOD OF RECEIVER, PLUS 
FIGURE A-17. Conclusion (terminator) sequences (continued). 


LEADING SOUND. SEND IT! 
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A.5.2.5.4 Valid sequences. 

The eight ALE words types that have been described shall be used to construct frames and 
messages only as permitted in figures A-18, A-19, and A-20. The size and duration of ALE 
frames, and their parts, shall be limited as described in table A-XII. 


TABLE A-XII. Limits to frames. 


Address size (5 words) (T, max) 1960 ms 


Call time maximum T, 4704 ms 
(one-half of T,, = 12 words max) 


Scan period (Ts max) 


Message section basic time (Tm max basic) (unless 
modified by AMD extension, or by CMD such as 


DTM or DBM) 


Message section, time limit of AMD (90 
characters) (Tin max AMD) 


Message section time, DTM (1053 2.29 min 
characters) (Tim max DTM) (entire data block) 


Message section time, DBM (37377 23.26 min 
characters) (Tin max DBM) (entire deeply interleaved block) 


A.5.2.5.5 Basic frame structure examples. 
Contained in figure A-21 are basic examples (does not include the optional message section) of 


frame construction. Included are single-word and multiple-word examples of either single or 
multiple called station address(es) for non-scan (single-channel) and scanning (multiple-channel) 
use in individual, net, or group calls. 
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SOUNDS, SCANNING OR NONSCAN 
NONSCAN_GROUP. 


VYNOR GP 2ND LOOP INT, 


(LOOP ALL PRESENT DESTNS) 


STRUCTURE 


| 
E 
ey 
oy 
© 
i 
a4 
< 
fo 
N 


END PRESENT DESTN 


XIMUMOF 12 WORDS 
IN ANY COMBINATION). 


ee 


SCANNING CALL T,, = nxTy LEADING CALL T,,=2T, 


CALLING CYCLE SECTION (HEADER) Ty, =1..+T, 


FIGURE A-18. Valid word sequence (calling cycle section). 
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SOUNDS, SCANNING OR NONSCAN 
CONCLUSION TERMINATOR AFTER END OF CALLING CYCLE T 
ORDERWIRE MESSAGE AFTER END OF > 
CMD ADDED OW MSGS 


QUICK ID (LOOP ALL CMD OW MSGS) 


FROM CMD 


WHOLE WHOLE 
ADDRESSES ORDERWIRE 
WORD 1 WORD 1 


SPECIAL DBM FORMAT 
ADDED OW. 


EXTENDED OW INFO 


EXTENDED ADRS 


END INCLUDED OW MSG 


DATA 


ADDRESS 
WORDS 2 & 4 


DATA 


ORDERWIRE 
EVEN WORDS 


END PRESENT XTMR ADRS 


EXTENDED ADRS EXTENDED OW_INFO 


EXTENDED ADRS EXTENDED OW_INFO 


REP 


ADDRESSES 
WORDS 3& 5 


REP 


ORDERWIRE 
ODD WORDS 


[o} 
a 
= 
< 
ro) 
{oe} 
pak | 
a 
= 
=< 
a 
a 
oe 
= 
a 


ORDERWIRE 
DATA 
BLOCK 
MESSAGE 


LQA, AMD, DTM... 


SSeS 


FIGURE A-19. Valid word sequence (message section). 
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XMTR ID SCNG REDUNDANT SOUND T,,, 
USING WHOLE ADRS 
(OR T,, 2Tx IF NONSCAN) 
(LOOP TO T,, /Tss END ONLY IF SOUNDING) 


© SOUNDS, SCANNING OR NONSCAN 5 


CONCLUSION TERMINATOR (AFTER END OF CALLING CYCLE T ,,.) 


Oe ae 


CONCLUSION TERMINATOR (AFTER END OF MSG T,,) 


@—_—.i_~ 


DATA 


ADDRESS 
WORDS 2& 4 


END OF FRAME STRUCTURE 


REP 


ADDRESSES 
WORDS 3& 5 


*SENDT. /T, /T, 
rs" x ° ‘srs 
FRAME TERMINATION 


a 
FIGURE A-20. Valid word sequence (conclusion section). 
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ot oi 
TO TO 
SAM SAM 


l 
SAM 


' 
. 1-CHANNEL NONSCAN, 2-WORD ADDRESSING, INDIVIDUAL (OR NET 


rt ‘Ig! "Wo! ‘To! "0! ‘0! 
oy oy sa 
. N-CHANNEL SCANNING, 2-WORD ADDRESSING, INDIVIDUAL (OR NET) CALL. 


ot Lot | | Lod 1st I ! Lot od tod 

THRU REP THRU REP REP 

Pp eck ee a 
. N-CHANNEL SCANNING, 1-WORD ADDRESSING, GROUP CALL. 


a Tec 

jg Tg AA ee 
It rot Lot | tot ro ot tot ot tot ot ot 
THRU REP THRU REP THRU REP TO DATA TO DATA TO DATA 
NOE os se eV 

. N-CHANNEL SCANNING, 2-WORD ADDRESSING, GROUP CALL. 


NOTE: VY denotes position of optional message section. 


FIGURE A-21. Basic frame structure examples. 


A.5.2.6 Synchronization. 
The ALE system is inherently asynchronous and does not require any form of system 


synchronization, although it is compatible with such techniques. Within a frame, the imbedded 
timing and structure of the system provide the necessary “hooks” for achieving and maintaining 
word synchronization (word sync) during linking, orderwire, and anti-interference functions, as 
described herein. 


A.5.2.6.1 Transmit word phase. 
The ALE transmit modulator accepts digital data from the encoder and provides modulated 


baseband audio to the transmitter. The signal modulation is strictly timed as described in A.5.1.3 
and A.5.1.4. After the start of the first transmission by a station, the ALE transmit modulator 
shall maintain a constant phase relationship, within the specified timing accuracy, among all 
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transmitted triple redundant words at all times until the final frame in the transmission is 
terminated. Specifically, 


Tater triple redundant word) ~ T Gearty triple redundant word) — nx Trw 


where T,) is the event time of a given triple redundant word within any frame, T, is the period of 
three words (392 ms), and n is any integer. 


NOTE: Word phase tracking will only be implemented within a transmission and not 
between transmissions. 


The internal word phase reference of the transmit modulator shall be independent of the receiver 
(which tracks incoming signals) and shall be self timed (within its required accuracy). See 
A.5.1.4. 


NOTE: In some applications, a single transmission may contain several frames. 


A.5.2.6.2 Receiver word sync. 
The receive demodulator accepts baseband audio from the receiver; acquires, tracks, and 


demodulates ALE signals; and provides the recovered digital data to the decoders. See figure 
A-11. In data block message (DBM) mode, the receive demodulator shall also be capable of 
reading single data bits for deep deinterleaving and decoding. 


A.5.2.6.3 Synchronization criteria. 
The decoder accepts digital data from the receive demodulator and performs deinterleaving, 


decoding, FEC, and data checking. During initial and continuing synchronization, all of the 
following criteria should be used to discriminate and read every ALE word: 


e Must meet or exceed a threshold of unanimous votes in the 2/3 majority voter decoder 
e Successful Golay decode of “A” word bits 

e Successful Golay decode of “B” word bits 

e Acceptable preamble according to valid word sequences as shown in figure A-14 

e Acceptable first character bits (of Basic 38 ASCII subset) 

e Acceptable second character bits (of Basic 38 ASCII subset) 

e Acceptable third character bits (of Basic 38 ASCII subset) 

e History, status, expectations, and protocol 


e Correct triple redundant word phase 


The number of unanimous votes provides an easily adjustable BER signal quality discrimination, 
and the threshold should be chosen by the manufacturer to optimize performance. A successful 
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Golay decode indicates that all detected bit errors were corrected within the power of the FEC 
code; that is, the errors were within correctable limits and therefore, the uncorrectable error 
flag(s) did not occur. The correction power (mode) of the Golay code should be chosen by the 
manufacturer to optimize performance using any of the four modes: (3/4, 2/5, 1/6, 0/7) where 
n/m indicates up to “n” errors detected and corrected, or up to ““m” errors detected but not 
correctable. Acceptable preambles, as described here and defined in A.5.2.3.1.3, refer to those 
preambles which are within the limits of this standard. As a DO, automatic adjustment of the 
unanimous vote threshold and Golay mode should be provided to optimize performance under 
varying conditions. 


NOTE: The application of each preamble is dependent on the recent signaling history of the 
stations heard, the active status of the machine, the handshake(s) expected, and the protocol 
being used, if any. For example, an uncommitted station, awaiting calls, would accept TO if 
individual or net call (and possibly THRU or REP if group call) as valid preambles for calls 
to it. It would reject CMD as being irrelevant (because it missed the preceding and required 
calling cycle T,,). It might also reject TIS or TWAS (unless collecting sounding 
information). Acceptable characters means that each character is within the appropriate 
ASCII subset. Note that all criteria, together, must be satisfied to accept a word. For 
example, all three characters would have to be within the Basic 38 ASCII subset if a routing 
preamble such as a TO was decoded. Likewise, any bit combination would be conditionally 
acceptable if an initial REP was received, but in most cases, without the necessary 
knowledge of the previous word, it would be considered irrelevant and should be rejected. 


A.5.3 Sounding. 


A.5.3.1 Introduction. 

The sounding signal is a unilateral, one-way transmission performed at periodic intervals on 
unoccupied channels. To implement, a timer is added to the controller to periodically initiate 
sounding signals (if the channel is clear). Sounding is not an interactive, bilateral technique, 
such as polling. However, the identification of connectivity from a station by hearing its 
sounding signal does indicate a high probability (but not guarantee) of bilateral connectivity and 
it may be done passively at the receiver. Sounding uses the standard ALE signaling, any station 
can receive sounding signals. As a minimum, the signal (address) information shall be displayed 
to the operator and, for stations equipped with connectivity and LQA memories, the information 
shall be stored and used later for linking. Ifa station has had recent transmissions on any 
channels that are to be sounded on, it may not be necessary to sound on those channels again 
until the sounding interval, as restarted from those last transmissions, has elapsed. In addition, if 
a net (or group) of stations is polled, their responses shall serve as sounding signals for the other 
net (or group) receiving stations. All stations shall be capable of performing periodic sounding 
on clear prearranged channels. The sounding capability may be selectively activated by, and the 
period between sounds shall be adjustable by the operator or controller, according to system 
requirements. When available, and not otherwise committed or directed by the operator or 
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controller, all ALE stations shall automatically and temporarily display the addresses of all 
stations heard, with an operator selectable alert. 


The structure of the sound is virtually identical to that of the basic call; however, the calling cycle 
is not needed and there is no message section. It is only necessary to send the conclusion 
(terminator) that identifies the transmitting station. See figure A-22. The type of word, either 
TIS or TWAS (but never both), indicates whether potential callers are encouraged or ignored, 
respectively. The minimum redundant sound time (T;,;) is equal to the standard one-word address 
leading call time (T\.)}=784 ms. Described below are both single-channel and multiple-channel 
protocols, plus detailed timing and control information, for designing stations. 


A.5.3.2 Single channel. 
The fundamental capability to automatically sound on a channel shall be in accordance with the 


sounding protocol as shown in figure A-22. As an option, stations may employ this protocol for 
single-channel sounding, connectivity tracking, and the broadcast of their availability for calls 
and traffic. The basic protocol consists of only one part: the sound. The sound contains its own 
address (“TIS A”). If “A” is encouraging calls and receives one, “A” shall follow the sound with 
the optional handshake protocol described in A.5.3.4. If “A” plans to ignore calls, it shall use the 
TWAS, which advises “B” and the others not to attempt calls, and then “A” shall immediately 
return to normal “available.” In some systems it is necessary for a multichannel station “A” to 
periodically sound to a single-channel network, usually to inform them that he is active and 
available on that channel, although scanning. Upon receipt of “A’s” sound, “B” (see figure A-23) 
and the other stations shall display “A’s” address as a received sound and, if they have an LQA 
and connectivity memory, they shall store the connectivity information. 


A.5.3.3 Multiple channels. 

Sounding must be compatible with the scanning timing. All stations shall be capable of 
performing the scanning sounding protocols described herein, even if operating on a fixed 
frequency. See figures A-22, A-23, and A-24. These protocols establish and positively confirm 
unilateral connectivity between stations on any available mutually scanned channel, and they 
assist in establishment of links between stations waiting for contact. Stations shall employ these 
protocols for multichannel sounding, connectivity tracking, and the broadcast of their availability 
for calls and traffic. 
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WORD TIME 
Ty, = 130.66 ...ms 


fe ae ee ee ee 


TWAS TWAS 


A A A 


SCANNING SOUND REDUNDANT SOUND 
(WHOLE ADDRESS WORDS) (WHOLE ADDRESS WORDS) 
Tyg = XT q (CALLER) = T,g= 21, (CALLER) > 2T,,, = 784ms 


NXT pw =nx392ms >T, 


© 


WAIT BUFFER 
2 


I 
I 
I 
uw 


TTUNE 


SCANNING REDUNDANT SOUND 
SOUNDING CYCLE 
Tors = Teg tT rs = (1+ 2)T , (CALLER) > 784 ms 


O© 


TIME 


-USE WHOLE ADDRESS ONLY. 


Ts 
Tg, (OPTIONAL IF NONSCAN). 


TWAS INDICATES CALL REJECTION. 


TIS INDICATES CALL ACCEPTANCE (A WILL PAUSE AFTERWARDS). 


NOTE: ©) DOES NOT APPLY TO THIS FIGURE. 


FIGURE A-22. Basic sounding structure. 
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TANNVHQ NO TISMd ONIAISOSY 
4O GOldAd SALVOIGNI 


(GV4¥ CNV) TIAMG Y3AISO34 ONINNVOS S, 
JO JONAGIDNIOD SALVOIGNI 


——— ‘GNOO5S SNO NI GANNVOS ‘NMOHS S1dWVX4 TANNVHO S 


‘NOILOSPSAY TIVO SALVOIGNI 
“AYNSI4 SIHL NO G3SnN LON 


“KINO SSANCCV FIOHM ASN- Ls . 
1) Gold NVOS NO SGN3d3d ( ) 3TOAD ONIGNNOS 


‘NIGNNOS 3YOI3¢ ( ) SWILL (NSLSIT) LIVM 


“TANNVHO HOVA NO 
ATIVILIN] GAYINOAY ONINAL 


OOOO" © 


S Updg = 6°) | . 
Swi 002 = (S SW POLb = 
(sis) SIOAO SNIGNNOS 


rotocol. 


in 


d 


lon scanning soun 


FIGURE A-23. Call reject 
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LXAN 


SS" 


aSNVd 8 ONIGNNOS 
"THNNVHO 


——— 


‘(SCUVMYALAV JSNVd THM ) SONVLddOOV TIVO SSLVOICNI 
“AYNSI4 SIHL NO GaSN LON 


“AYNSI4 SIHL NO GaSN LON 


‘AINO SS3YNCdV FTOHM SSn- 


9=STIVO 


Sha Gad wod ASNVd Z 


OOOO” 


ee OOO@- OOO 


ey 


é 


‘ 
i 
I 
i 


‘TIHMG 


rotocol. 


FIGURE A-24. Call acceptance scanning soundin 
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All timing considerations and computations for individual scanning calling shall apply to 
scanning sounding, including sounding cycle times and (optional) handshake times. 


NOTE: The scanning sound is identical to the single-channel sound except for the extension 
of the redundant sound time (T;;) by adding words to the scan sounding time (T;;) to form a 
scanning redundant sound time (Tss); that is Ts; = Tss + T:s. The scan sounding time (T,s) is 
identical in purpose to the scan calling time (T;,) for an equivalent scanning situation, but it 
only uses the whole address of the transmitter. 


The channel-scanning sequences and selection criteria for individual scanning calling shall also 
apply to scanning sounding. The channels to be sounded are termed a “sound set,” and usually 
are identical to the “scan set” used for scanning. See figure A-23. In this illustration, station “A” 
is sounding and station “B” is scanning normally. Ifa station “A” plans to ignore calls (from 
“B”), which may follow “A’s” sound, the following call rejection scanning sounding protocol 
shall be used. In a manner identical to the previously described individual scanning call, “A” 
lands on the first channel in the scan set (1), waits (Twt) to see if the channel is clear (3), tunes 
(T;) its coupler, comes to full power, and initiates the frame of the scanning redundant sound 
times (Ts). This scanning sound is computed to exceed “B’s” (and any others) scan period (Ts) 
by at least a redundant sound time (T;s), which will ensure an available detection period 
exceeding Taw = 784 ms. In this five-channel example, with “B” scanning at 5 chps, “A” sounds 
for at least 12 Ty (4704 ms). “A” also uses “TWAS A,” redundantly to indicate that calls are not 
invited. Upon completion of the scanning sounding frame transmission, “A” immediately leaves 
the channel and goes to the next channel in the sound set. This procedure repeats until all 
channels have been sounded, or skipped if occupied. When the calling ALE station has 
exhausted all the prearranged sound set channels, it shall automatically return to the normal 
“available” receive scan mode. As shown in figure A-23, the timing of both “A” and “B” have 
been prearranged to ensure that “B” has at least one opportunity, on each channel, to arrive and 
“capture” “A’s” sound. Specifically, “B” arrives, detects sounds, waits for good words, reads at 
least three (redundant) “TWAS A” (in 3 to 4 T,), stores the connectivity information (if capable), 
and departs immediately to resume scan. 


There are several specific protocol differences when station “A” plans to welcome calls after the 
sound. See figure A-24. In this illustration, “A” is sounding and “B” is scanning normally. If 
station “A” plans to welcome calls (from “B”), which may follow his sound, the following call 
acceptance scanning sounding protocol shall be used. In this protocol, “A” sounds for the same 
time period as before. However, since “A” is receptive to calls, he shall use his normal scanning 
dwell time (Tq) or his preset wait before transmit time (Ty), whichever is longer, to listen for 
both channel activity and calls before sounding. If the channel is clear, “A” shall initiate the 
scanning sound identically to before, but with “TIS A.” At the end of the sounding frame, “A” 
shall wait for calls identically to the wait for reply and tune time (Tyr) in the individual scanning 
calling protocol, in this case shown to be 6 Ty (for fast-tuning stations). During this wait, “A” 
shall (as always) be listening for calls that may coincidentally arrive even though unassociated 
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with “‘A’s” sound, plus any other sound heard, which “A” shall store as connectivity information 
if polling-capable. If no calls are received, “A” shall leave the channel. 


A.5.3.4 Optional handshake. 

In the previous descriptions, one alternative action is the implementation of an optional 
handshake with a station immediately after its sound. This protocol is identical in all regards to 
the single channel individual call protocol, except that it is manually or automatically (operator 
or controller) triggered by acquisition of connectivity from the station that is to be called. See 
figure A-25. In this illustration, “A” is scanning sounding and is receptive to calls, and “B” is 
receive scanning (or waiting in ambush on a channel) and requires contact with “A” if heard. 
“A” uses the standard call acceptance scanning sound, including the “TIS A” and the pause for 
calls. In this case “B” calls “A.” When ALE stations are scanning sounding and receptive to 
calls, or required contact with such a station, the optional handshake protocol should be used. 
The calling station should immediately initiate the call upon the determination that the station to 
be called has terminated its transmission. A wait time before transmit time is not required. 
Therefore, if “B” hears “A’s” sound and is seeking “A,” “B” calls immediately using the simple 
single-channel call. Also, if “B’s” operator or controller identifies “A’s” address it can attempt 
the optional handshake. 
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A.5.4 Channel selection. 

Channel selection is based on the information stored within the LQA memory (such as BER, 
SINAD, and MP) and this information is used to speed connectivity and to optimize the choice of 
quality channels. When initiating scanning (multichannel) calling attempts, the sequence of 
channels to be tried shall be derived from information in the LQA memory with the channel(s) 
with the “best score(s)” being tried first (unless otherwise directed by the operator or controller) 
until all the LQA scored channels are tried. However, if LQA or other such information is 
unavailable (or it has been exhausted and other valid channels remain available and untried) the 
station shall continue calling on those channels until successful or until all the remaining (untried 
valid) channels have been tried. 


A.5.4.1 LQA. 

LQA data shall be used to score the channels and to support selection of a “best” (or an 
acceptable) channel for calling and communication. LQA shall also be used for continual 
monitoring of the link(s) quality during communications that use ALE signaling. The stored 
values shall be available to be transmitted upon request, or as the network manager shall direct. 
Unless specifically and otherwise directed by the operator or controller, all ALE stations shall 
automatically insert the CMD LQA word (¥) in the message section of their signals and 
handshakes when requested by the handshaking station(s), when prearranged in a network, or 
when specified by the protocol. See A.5.4.2. Ifan ALE station requires, and is capable of using 
LQA information (polling-capable), it may request the data from another station by setting the 
control bit KA1 to “1” in the CMD LQA word. If an ALE station, which is sending CMD LQA 
in response to a request is incapable of using such information itself (not polling-capable), it shall 
set the control bit KA1 to “0.” It will be a network management decision to determine if the 
LQA is to be active or passive. For human factor considerations, LQA scores that may be 
presented to the operator should have higher (number) scores for better channels. 


A.5.4.1.1 BER. 

Analysis of the BER on rf channels, with respect to poor channels and the 8-ary modulation, plus 
the design and use of both redundancy and Golay FEC, shows that a coarse estimate of BER may 
be obtained by counting the number of non-unanimous (2/3) votes (out of 48) in the majority 
vote decoder. The range of this measure is 0 through 48. Correspondence to actual BER values 
is shown in table A-XIII. 


After an ALE receiver achieves word synchronization (see A.5.2.6.2), all received words in a 
frame shall be measured, and a linear average BER/LQA shall be computed as follows: 


e Ifthe Golay decoder reports no uncorrectable errors in both halves of the ALE word, the 
number of non-unanimous votes detected in the word shall be added to the total. 


e If at least one half of the ALE word contained uncorrectable errors, the number of non- 
unanimous votes detected shall be discarded, and 48 (the maximum value) shall be added 
to the total. 


115 


MIL-STD-188-141B 
APPENDIX A 


At the end of the transmission, the total shall be divided by the number of words received, and 
the total shall be stored in the Link Quality Memory as the most current BER code for the station 
sending the measured transmission and the channel that carried it. 


A.5.4.1.2 SINAD. 

The signal to noise and distortion measurement shall be a SINAD measurement 
((S+N+D)/(N+D)) averaged over the duration of each received ALE signal. The SINAD values 
shall be measured on all ALE signals. 


A.5.4.1.3, MP (optional). 


Measurement of MP using received ALE signals is optional. 


A.5.4.1.4 Operator display (optional). 
Display of SINAD values shall be in dB. 


A.5.4.2 Current channel quality report (LQA CMD). 

This mandatory function is designed to support the exchange of current LQA information among 
ALE stations. The CMD LQA word shall be constructed as shown in table A-XIV The 
preamble shall be CMD (110) in bits P3 through P1 (W1 through W3). The first character shall 
be “a” (1100001) in bits C1-7 through C1-1 (W4 through W10), which shall identify the LQA 
function “analysis.” It carries three types of analysis information (BER, SINAD, and MP) which 
are separately generated by the ALE analysis capability. Note that when the control bit KA1 
(W11) is set to “1,” the receiving station shall respond with an LQA report in the handshake. If 
KA1 is set to “0,” the report is not required. 


A.5.4.2.1 BER field in LQA CMD. 

Measurement and reporting of BER is mandatory. The BER field in the LQA CMD shall contain 
five bits of information, BES through BE1 (W20 through W24). Refer to table A-XIII for the 
assigned values. 


A.5.4.2.2 SINAD. 

SINAD shall be reported in the CMD LQA word as follows. The SINAD is represented as five 
bits of information SN5 through SN1 (W15 through W19). The range is 0 to 30 dB in 1-dB 
steps. 00000 is 0 dB or less, and 11111 is no measurement. 


A.5.4.2.3, MP. 

If implemented, MP measurements shall be reported in CMD LQA words in the three bits, MP3 
through MP1 (W12 through W14). The measured value in ms shall be reported rounded to the 
nearest integer, except that values greater than 6 ms shall be reported as 6 (110). When MP is 
not measured, the reported MP value shall be 7 (111). 
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TABLE A-XIII. Approximate BER values. 


LQA Transmission Bits 
Average 2/3 Approximate 
Votes Counted S BER 


1 : 
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TABLE A-XIV. Link quality analysis structure. 


LQA Bits Word Bits 
CMD MSB 
Preamble 


First 
Character 


6699 


a 


MP MSB MP3 Wi12 
Bits MP2 W113 
LSB MP1 Wi14 


SINAD 
Bits 


NOTES: 
1. Command LQA first character is “a” (1100001) for “analysis.” 
2. Control bit KA1 (W11) requests an LQA within the handshake from the called station, if set to “1,” 
and suppresses LQA if set to “0.” 


A.5.4.3 Historical LQA report. 
See MIL-STD-187-721. 


A.5.4.4 Local noise report CMD (optional). 


The Local Noise Report CMD provides a broadcast alternative to sounding that permits receiving 
stations to approximately predict the bilateral link quality for the channel carrying the report. An 
example application of this optional technique is networks in which most stations are silent but 
need to have a high probability of linking on the first attempt with a base station. A station 
receiving a Local Noise Report can compare the noise level at the transmitter to its own local 
noise level, and thereby estimate the bilateral link quality from its own LQA measurement of the 
received noise report transmission. The CMD reports the mean and maximum noise power 
measured on the channel in the past 60 minutes. 
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The Local Noise Report CMD shall be formatted as shown in figure A-26. Units for the Max 
and Mean fields are dB relative to 0.1 pV 3 KHz noise. If the local noise measurement to be 
reported is 0 dB or less, a 0 is sent. For measured noise ratios of 0 dB to +126 dB, the ratio in dB 
is rounded to an integer and sent. For noise ratios greater than +126 dB, 126 is sent. The code 
127 (all 1s) is sent when no report is available for a field. By comparing the noise levels reported 
by a distant station on several channels, the station receiving the noise reports can select a 
channel for linking attempts based upon knowledge of both the propagation characteristics and 
the interference situation at that destination. 


FIGURE A-26. Local noise report (optional). 


A.5.4.5 Single-station channel selection. 
All stations shall be capable of selecting the (recent) best channel for calling or listening for a 
single station based on the values in the LQA memory. 


A.5.4.5.1 Single-station channel selection for link establishment. 

When selecting a channel for a two-way link, link quality measurements for both directions on 
each frequency must be considered. Figure A-27 represents a simple LQA memory example. 
For each address/channel cell, the measured LQA (upper section) and reported LQA values 
(lower section) are stored. Bilateral (handshake) scores in this example are the sum of the two 
LQA values. 


NOTE 1: For operator viewing, LQA values for better channels should be displayed as 
higher numbers, and values for poorer channels should be displayed as lower numbers. 


NOTE 2: In the example shown in figure A-27, if a handshake is required with station “B,” 
channel C3 would be the best because the “round trip” (bilateral) score would be 5 (1+4), 
thus the lowest, channel C4 is next best with a score of 6 (3+3), the C5 with 7, C2 with 12, 
and C6 with 18. Linking attempts should be made in that order (C3, C4, C5, C2, and C6). 


C1 is left until last because of the “x”, which indicates that a recent attempted handshake on 
that channel failed to link. Similarly, an attempt to call “A” would yield the sequence C3(3), 
C5(12), C2(12), C1(24), C6(26), and C4(x). In this case, C5 was equal to C2 (both are 12), 
but C5 was chosen first because the paths were more balanced (LQA values were more 
equal). 
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LOA SCORE 
NOTES: 
1. Upper value is LQA measurement on received signal from other stations. 
2. Lower value is LQA measure on transmitted signal to other station as received and 
reported back. 

3. Example shows range of 0 to 30 for LQA “scores,” with a smaller value being better. 
*LQA = “0” is excellent, ranging down to “30” which is very poor. 
*LQA = “x” indicates none available after handshake attempt. 
*LQA = “-” indicates none available but handshake not tried. 


FIGURE A-27. LQA memory example. 
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A.5.4.5.2 Single-station channel selection for one-way broadcast. 

If only a one-way transmission to a station is required instead of a handshake, the scores reported 
by the destination station (TO section in figure A-27) should be given greater weight than the 
scores measured on transmissions from that station. 


NOTE: In the example, to reach “B,” the sequence would be C4(3), C3(4), C5(5), C2(7), 
C6(12), and C1(x) as a last resort. 


A.5.4.5.3 Single-station channel selection for listening. 

When selecting a channel to listen for another station, the scores measured on transmissions from 
that station (FROM section in figure A-27) should be given greater weight than the scores 
reported by the destination station. 


NOTE: In the example, to listen for “A,” channel C4(0) would be best, and if only three 
channels were to be scanned, they should be C4, C3, and C2. 


A.5.4.6 Multiple-station channel selection. 
A station shall also be capable of selecting the (recent) best channel to call or listen for multiple 
stations, based on the values in the LQA memory. 


NOTE: In the example shown in figure A-27, if a multiple-station handshake is required 
with stations “B” and “C,” C5 is the best choice as the total score is 12 (2+5+3+2), followed 
by C4 (20) and C3 (35). Next would be C2 (34+) and C6 (36+), this ranking being due to 
their unknown handshake capability (which had not been tried). C1(x) is the last to be tried 
because recent handshake attempts had failed for both “B” and “C.” To call the three 
stations “A,” “B,” and “C,” the sequence would be C5 (24), C3 (38), C2 (46+), C6 (62+), C4 
(one x) (recently failed attempt), and finally C1 (two x). 


If an additional selection factor is used, it will change the channel selection sequence. 


NOTE: In the example, to call “D” and “E,” the sequence would be C2, C3, C4, C5, Cl, 
and C6. Ifa maximum limit of LQA < 14 is imposed on any path (to achieve a minimum 
circuit quality), only C2 and C3 would be initially selected for the linking attempt. Further, 
if the LQA limit was “lowered” to 10, C3 would be selected before C2 for the linking 
attempt. 


If a broadcast to multiple stations is required, the TO section (“to” the station) scores are given 
priority. 


NOTE: In the example, to broadcast to “B” and “C,” the sequence would be C5(7), C4(9), 
C3(21), C2(7+), C6(12+), and C1(two x). 
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To select channels for listening for multiple stations, the FROM section (“from”’ the station) 
scores are given priority. 


NOTE: In the example, to listen for “A” and “B,” channel C2 (2) would be best, and if only 
four channels could be scanned, they should be C2, C3, C4, and CS. 


A.5.4.7 Listen before transmit. 

Before initiating a call or a sound on a channel, an ALE controller shall listen for a 
programmable time (Ty) for other traffic, and shall not transmit on that channel if traffic is 
detected. Normally, a sound aborted due to detected traffic will be rescheduled, while for a call 
another channel shall be selected. 


A.5.4.7.1 Listen-before-transmit duration. 

The duration of the listen-before-transmit pause shall be programmable by the network manager. 
When the selected channel is known to be used only for ALE transmissions, the listen-before- 
transmit delay need be no longer than 2 T,y. For other channels, at least 2 seconds shall be used. 
When an ALE controller was already listening on the channel selected for a transmission, the 
time spent listening on the channel may be included in the listen-before-transmit time. 


A.5.4.7.2 Modulations to be detected. 

The listen-before-transmit function shall detect traffic on a channel in accordance with A.4.2.2. 
This may be accomplished using any combination of internal signal detection and external 
devices that provide a channel busy signal to the ALE controller. 


A.5.4.7.3 Listen before transmit override. 
The operator shall be able to override both the listen-before-transmit pause and the transmit 
lockout (for emergency use). 


A.5.5 Link establishment protocols. 
An ALE controller shall control an attached HF SSB radio to support both manual and automatic 
link operation as described in the following paragraphs. 


A.5.5.1 Manual operation. 

The ALE controller shall support emergency control by the operator. Each ALE controller shall 
provide a manual control capability to permit an operator to directly operate the basic SSB radio 
in emergency situations. At all other times, the radio shall be under automated control, and the 
operator should operate the radio through its associated controller. The ALE controller’s 
receiving and passive collection capability to be “always listening,” such as monitoring for 
sounding signals or alerting the operator, shall not be impaired. 


NOTE: This does not abrogate the manual push-to-talk operation required by 4.2.2. 
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A.5.5.2 ALE. 

The fundamental protocol exchange for link establishment shall be the three-way handshake (see 
Appendix I for overview of Selective Calling). A three-way handshake is sufficient to establish a 
link between a calling station and a responding station. With the addition of slotted responses 
(described in A.5.5.4.2), the same call/response/acknowledgment sequence can also link a single 
calling station to multiple responding stations. 


A.5.5.2.1 Timing. 

The ALE system depends on a selection of timing functions for optimizing the efficiency and 
effectiveness of ALE. The primary timing functions and values as listed in table A-XV. Annex 
A defines the timing symbols and Annex B explains the timing analysis and computation. 


A.5.5.2.2 ALE states. 
An ALE controller may be referred to as being in one of three conceptual “states.” See figure 
A-28. 


Available 


Link Rejected (caller) 


Link Establishment Succeeds 


FIGURE A-28. Link establishment states. 


A.5.5.2.3, ALE channel selection. 

A scanning calling station shall send ALE calls on its scanned channels in the order dictated by 
its channel selection algorithm. It shall link on the first channel it tries that supports a handshake 
with the called station(s). 
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A.5.5.2.3.1 Rejected channel. 

If a channel is rejected after linking by the operator or controller as unsuitable, the ALE 
controller shall terminate the link in accordance with A.5.5.3.5 and shall update LQA data using 
measurements obtained during linking. 


A.5.5.2.3.2 Busy channel. 

During the scanning-calling cycle, a caller may encounter occupied channels and shall skip them 
to avoid interference to traffic and activity. After all available channels have been tried, if no 
contact has been successful, the caller should revisit the previously occupied channels and, if 
they are free, attempt to call. 


A.5.5.2.3.3, Exhausted channel list. 

If a calling station has exhausted all of its prearranged scan set channels and failed to establish a 
link, it shall immediately return to normal receive scanning (the available state). It shall also 
alert the operator (and networking controller if present) that the calling attempt was unsuccessful. 


A.5.5.2.4 End of frame detection. 

ALE controllers shall identify the end of a received ALE signal by the following methods. The 
controller shall search for a valid conclusion (TIS or TWAS, possibly followed by DATA and 
REP for a maximum of five words, or Tx max). The conclusion must maintain constant redundant 
word phase within itself (if a sound) and with associated previous words. The controller shall 
examine each successive redundant word phase (T,,) following the TIS (or TWAS) for the first 
(of up to four) non-readable or invalid word(s). Failure to detect a proper word (or detection of 
an improper word) or detection of the last REP, plus the last word wait delay time, (Tiww or Trw), 
shall indicate the end of the received transmission. The maximal acceptable terminator sequence 
is TIS (or TWAS), DATA, REP, DATA, REP. 
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TABLE A-XV. Timing. 


NOTE: Refer to annex A and annex B for details. 
Basic system timing 


Tone rate = 125 symbols per second (sps) 
Tone period = Ttone = 8 ms 


On-air rate = 375 b/s 

On-air word: T,, = 130.66... ms 

On-air redundant word: T,, =3 Ty = 392 ms 

On-air leading redundant words: Tw =2 T,w = 784 ms 

On-air individual (net) address time: T, =m x T,, for m= 1 to 5 jax words. 
T, = 392 ms to 1960 ms 

Propagation: T, = 0 to 70 ms 


System timing limits 


Address size limit 5 words: T, max = 1960 ms 
Address first word limit: T,) = 392 ms 
Call time maximum: T, = 4704 ms (one-half of T,, = 12 words max) 


Group addresses first word limit: T,; = 1960 ms 

Maximum scan period: Ts max = 50s 

Message section basic time (unless modified by AMD extension, or by CMD (such as DTM or 
DBM)): Tin max basic = 11.76s 

Message section time limit, AMD (90 characters): Tin max AMD = 11.76s 

Message section time limit, DTM (1053 characters): Tin max DTM = 2.29 min (entire data 
block) 

Message section time limit, DBM, (37377 characters): Ti max DBM = 23.26 min (entire deeply 
interleaved block with CMD) 

Termination time limit: Ty max = 1960 ms 


If an ALE (orderwire) protocol such as AMD, DTM, or DBM is used to extend the basic message section, it 
shall start no later than the start of the 30th word (11.368 s). Such extension of the message section shall be 
determined by the length of the extended ALE protocol, and the message section shall terminate at the end of 
the orderwire without additional extension. The conclusion shall start at the end of the message section. 


Individual calling 


Minimum dwell time: Tg (5) min = 200 ms, basic receive scanning (5 channels per second) 
Minimum dwell time: Tg (2) min = 500 ms minimum receive scanning (2 channels per second (chps)) 
Probable maximum dwell per channel, for channel, for T, computations, let Ty = Tay =784 ms 
Number of channels: C 

Scan period: T,=Cx Ty 

Call time: T, = T, (one or more whole addresses as required & T,) in T,, 

Call time (Group Call): T= T, (one or more different first words, & T,)) in T., 

Leading call time: T|,=2 T, 

Redundant call time: T,, = T,, + Ty 

Scanning call time: T,.=nx Ty = T, 

Calling cycle time: T,..= Typ + Ty, 2 Ts + Te 

Scanning redundant call time: Tyc = Tse + Tre 

Last word wait delay: Thy = Try = 392 ms 
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TABLE A-XV. Timing (continued). 


e Wait for response time delay: Ty, = Ty + Tp + Tiww + Tra + Tryp (if not first transmission...) + Tig + T, 

+ Tyg 

Late detect delay: Tig = Ty = 130.66...ms 

Redundant word phase delay: T,,,, = 0 to T,, (0 to 392 ms) 

Turnaround time: Ti, = Tra + Taek + Tenk + Tte + Tae + Tia 

Wait for calling cycle end time: T,.¢=2 x own T, (default) 

Tune time: T; (as required by slowest tuner) 

Wait for reply and tune time: T,,,,= Ty, + T; 

e Detect signaling period: Ty, < (Ty(5) = 200 ms) 

e Detect redundant word period: Taw = Try + spare Tw = 784 ms 

e Detect rotating redundant word period: Tany = 2 Try + spare 
Ty = 1176 ms 


Sounding 
e Redundant sound time (similar to T),): T,,;=2 T, (caller) 
e Scanning sound time (similar to T,.): T,.=n x T, (caller) = T 
e Scanning redundant sound time (similar to T..): Tos = Tss + Tis 2 Ts + Ts 
Star calling 
e Minimum standard slot widths: T,, min = 14, 17 T, for Ist handshake slots, or 17, 20 for subsequent 
handshake slots, or other T,, as set by CMD. 
Slot widths: T,, = 14, 17, 9, or other T,, 
Slot number: SN 
Slot wait time: Ty = Tsw x SN (uniform case) 
Slot wait time (delay to start reply): T,,, for each slot is the sum of all the previous slot times and so 
must be different for each slot and is cumulative. T.y(SN) = Ts, x SN for uniform slots or generally 
Tywi(SN) = SN x [5 T, + 2 T, (caller) + (optional LQA)T,,, + (optional message)T,,,] + T, (caller) + 
[(sum of all previous called addressed) 
m=SN-1 
 T,(m) (called)] 
m=! 
Number of slots: NS 
Wait for net reply (at calling station): Tym =(Tsy x NS) for uniform slots, or generally Tyin = 
Tyyi(NS) 
Wait for net acknowledgment (at called stations): Tyan = Twin + Taw 


Turnaround and tune limits: Tj, + T,< 360, 2100, or 1500 ms, depending on whether slot 0, 1, or 
others 


Maximum star group wait for acknowledgment: Twan max = 107 Ty, + 27 T, (caller) + 13 T,. (optional 
LQA) + 13 Tin (optional message) 


For late arrival stations, if caller uses one word addresses and no message calling: Twan max = 188 Ty, 
or 227 Ty if LQA 


Programmable timing parameters: typical values 


Wait (listen first): T,,=2 seconds, general uses; = 784 ms, ALE/data only channels 
Tune time: T, = 8 T,, = 1045.33...ms (default), “blind” first call; = 20 seconds, next try 
Automatic sounding: T,, = 30 minutes 


Wait for activity: T,, = 30 seconds 
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A.5.5.3 One-to-one calling. 

The protocol for establishing a link between two individual stations shall consist of three ALE 
frames: a call, a response, and an acknowledgment. The sequence of events, and the timeouts 
involved, are discussed in the following paragraphs using a calling station SAM and a called 
station JOE. 


A.5.5.3.1 Sending an individual call. 

After selecting a channel for calling, the calling station (SAM) shall begin the protocol by first 
listening on the channel to avoid “disturbing active channels,” and then tuning. If the called 
station (JOE) is known to be listening on the chosen channel (not scanning), the calling station 
shall transmit a single-channel call that contains only a leading call and a conclusion (see upper 
frame in figure A-29). Otherwise, it shall send a longer calling cycle that precedes the leading 
call with a scanning call of sufficient length to capture the called station’s receiver as it scans 
(lower frame in figure A-29). The duration of this scanning call shall be 2 T,,, for each channel 
that the called station is scanning. The scanning call section shall contain only the first word of 
the called station address, using a TO preamble, and repeated as necessary until the end of the 
scanning call section. 


Scanning Call Leading Call Conclusion 


TO | IO |} US 
JOE | JOE || SAM 


JOE | JOE |" °° | JOE | JOE | JOE | JOE 


FIGURE A-29. Individual calls. 


The entire called station address shall be used in the leading call section, and shall be sent twice 
(see figure A-29) using a TO preamble each time the first word is sent and DATA and REP as 
required for additional words. 


Any message section CMDs shall be sent immediately following the leading call, followed by a 
conclusion containing the complete calling station address (“TIS SAM”). The calling station 
shall then wait a preset reply time to start to receive the called station’s response. In the single- 
channel case, the wait for reply time shall be T,,,, which includes anticipated round trip 
propagation delay and the called station’s turnaround time. In the multi-channel case, the calling 
station shall wait through a wait for reply and tune time (Ty), which also includes time for the 
called station to tune up on the chosen channel. 
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If the expected reply from the called station does not start to arrive within the preset wait for 
reply time (Ty,) or wait for reply and tune time (Twit), the linking attempt on this channel has 
failed. At this point, if other channels in the scan set have not been tried, the linking attempt will 
normally start over on a new channel. Otherwise, the ALE controller shall return to the available 
state, and the calling station’s operator or networking controller shall be notified of the failed 
linking attempt. 


A.5.5.3.2 Receiving an individual call. 

When the called station (JOE) arrives on channel, sometime during its scan period Ts, and 
therefore during the calling station SAM’s longer scan calling time Tc, the called station shall 
attempt to detect ALE signaling within its dwell time. If ALE signaling is detected, and the 
controller achieves word sync, it shall examine the received word to determine the appropriate 
action. 


If JOE reads “TO JOE” (or an acceptable equivalent according to protocols), the ALE controller 
shall stop scan, enter the linking state, and continue to read ALE words while waiting a preset, 
limited time Tyce for the calling cycle to end and the message or conclusion to begin. 


e Ifthe received word is potentially from a sound or some other protocol, the ALE 
controller shall process the word in accordance with that protocol. 


e Otherwise, the ALE controller shall resume its previous state (e.g., available if it was 
scanning, linked if it was linked to another station). 


While reading a call in the linking state, the called station shall evaluate each new received word. 
The controller shall immediately abort the handshake and return to its previous state upon the 
occurrence of any of the following: 


e It does not receive the start of a quick-ID, message, or frame conclusion within Tyce, or 
the start of a conclusion within Tmmax after the start of the message section; 


e Any invalid sequence of ALE word preambles is received, except that during receipt of a 
scanning call, up to three contiguous words containing uncorrectable errors shall be 
tolerated without causing rejection of the frame; 


e The end of the conclusion is not detected within Tiww, (plus the additional multiples of 
Tw if an extended address) after the first word of the conclusion. 


If a quick-ID or a message section starts within Tyce, the called station, (JOE) shall attempt to 
read one or more complete messages within a new preset, limited time Tmax 


If a frame conclusion starts “TIS SAM,” the called station shall wait and attempt to read the 
calling station’s address (SAM) within a new preset, limited time Txmax. 


If an acceptable conclusion sequence with TIS is read, the called station shall start a “last word 

wait” timeout Tiww = Trw while searching for additional address words (if any) and the end of the 
frame (absence of a detected word), which shall trigger its response. The called station will also 
expect the calling station to continue the handshake (with an acknowledgment) within the called 
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station’s reply window, Tyr, after its response. If TWAS is read instead, the called station shall 
not respond but shall return to its previous state immediately after reading the entire calling 
station address. 


If all of the above criteria for responding are satisfied, the called station shall initiate an ALE 
response immediately after detecting the end of the call, unless otherwise directed by the operator 
or controller. 


A.5.5.3.3 Response. 

Upon receipt of a call that is addressed to one of its own self addresses (JOE), and which 
contains a valid calling station address in a TIS conclusion (SAM), the called station shall listen 
for other traffic on the channel. If the channel is not in use, the station shall tune up, send a 
response (figure A-30), and start its own reply timer Ty;. (The longer Ty, timeout is not 
necessary unless the calling station will send its acknowledgment on a different channel than the 
one carrying the call, requiring re-tuning.) If the channel is in use, the ALE controller shall 
ignore the call and return to its previous state unless otherwise programmed. 


FIGURE A-30. Response frame. 


If the calling station (SAM) successfully reads the beginning of an appropriate response (“TO 
SAM”’) starting within its timeout (either T,, or Twit), it shall process the rest of the frame in 
accordance with the checks and timeouts described above for the call until it either aborts the 
handshake or receives the appropriate conclusion, which in this example is “TIS JOE.” 
Specifically, the calling station shall immediately abort the handshake upon the occurrence of any 
of the following: 


e It does not receive an appropriate response calling cycle (“TO SAM”) starting within the 
timeout; 


e An invalid sequence of ALE word preambles occurs; 


e It does not receive the appropriate conclusion (“TIS JOE”) starting within Ti, (plus Tm max; 
if message included); 


e The end of the conclusion is not detected within Ti, (plus the additional multiples of 
Tw if an extended address). 


After aborting a handshake for any of the above reasons, the calling station will normally restart 
the calling protocol, usually on another channel. 


129 


MIL-STD-188-141B 
APPENDIX A 


If the calling station receives the proper conclusion from the called station (“TIS JOE”) starting 
within Ti, (plus Tm max, if message included), it shall set a last word wait timeout as above and 
prepare to send an acknowledgment. If, instead, “TWAS JOE” is received, the called station has 
rejected the linking attempt, the calling station ALE controller shall abort the linking attempt and 
inform the operator of the rejected attempt. 


A.5.5.3.4 Acknowledgment. 

If all of the above criteria for an acceptable response are satisfied, and if not otherwise directed 
by the operator or networking controller, the calling station ALE controller shall alert its operator 
that a correct response has been received, send an ALE acknowledgment (see figure A-31), enter 
the linked state with the called station (JOE), and unmute the speaker. 


ake) TO Us 
JOE | JOE || SAM 


FIGURE A-31. Acknowledgment frame. 


A “wait for activity” timer Twa shall be started (with a typical timeout of 30 seconds) that shall 
cause the link to be dropped if the link remains unused for extended periods (see A.5.5.3.5). 


If the called station (JOE) successfully reads the beginning of an appropriate acknowledgment 
(“TO JOE”) starting within its Ty, timeout, it shall process the rest of the frame in accordance 
with the checks and timeouts described above for the response until it either aborts the handshake 
or receives the appropriate conclusion, which in this example is “TIS SAM” or “TWAS SAM.” 
Specifically, the calling station shall immediately abort the handshake upon the occurrence of any 
of the following: 


e It does not receive an appropriate response calling cycle (“TO JOE”) starting within its 
Twr timeout; 


e An invalid sequence of ALE word preambles occurs; 


e It does not receive the appropriate conclusion starting within T), after the start of the 
frame (plus Tm max, if message included); 


e The end of the conclusion is not detected within Ti, (plus the additional multiples of 
Tiw if an extended address). 
If the handshake is aborted for any of the above reasons, the handshake has failed, and the called 
station ALE controller shall return to its pre-linking state. The called station shall notify the 
operator or controller of the failed linking attempt. 


Otherwise, the called station shall enter the linked state with the calling station (“SAM”), alert 


the operator (and network controller if present), unmute the speaker, and set a wait-for-activity 
timeout Twa. 
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NOTE 1: Although SAM’s acknowledgment to JOE appears identical to a single-channel 
individual call from SAM to JOE, it does not cause JOE to provide another response to the 
acknowledgment (resulting in an endless “ping-pong” handshake) because SAM’s 
acknowledgment arrives within a narrow time window (Tyr) after JOE’s response, and an 
acknowledge (ACK) from SAM is expected within this window. If SAM’s acknowledgment 
arrives late (after Ty), however, then JOE must treat it as a new individual call (and shall 
therefore send a new response, if SAM concludes the frame with TIS). 


NOTE 2: A typical one-to-one scanning call three-way handshake takes between 9 and 14 
seconds. 


A.5.5.3.5 Link termination. 

Termination of a link after a successful linking handshake shall be accomplished by sending a 
frame concluded with TWAS to any linked station(s) which is (are) to be terminated. For 
example, “TO JOE, TO JOE, TWAS SAM” (when sent by SAM) shall terminate the link 
between stations SAM and JOE. JOE shall immediately mute and return to the available state, 
unless it still retains a link with any other stations on the channel. Likewise, SAM shall also 
immediately mute and return to the available state, unless it retains a link with any other stations 
on the channel. 


A.5.5.3.5.1 Manual termination. 

A means shall be provided for operators to manually reset a station, which shall mute the 
speaker(s), return the ALE controller to the available state, and send a link terminating (TWAS) 
transmission, as specified above, to all linked stations, unless this latter feature is overridden by 
the operator. (DO: provide a manual disconnect feature that drops individual links while leaving 
others in place.) 


A.5.5.3.5.2 Automatic termination. 

If no voice, data, or control traffic is sent or received by a station within a preset time limit for 
activity (Twa), the ALE controller shall automatically mute the speaker, terminate the linked state 
with any linked stations, and return to the available state. The wait for the activity timer is 
mandatory, but shall also be capable of being disabled by the operator or network manager. This 
timed reset is not required to cause a termination (TWAS) transmission, as specified above. 
However, it is recommended that a termination be sent to reset the other linked stations(s) to 
immediately return them to the available state. 


Termination during a handshake or protocol by the use of TWAS (or a timer) should cause the 
receiving (or timed-out) station to end the handshake or protocol, terminate the link with that 
station, re-mute, and immediately return to the available state unless it still retains a link with 
another station. 
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A.5.5.3.6 Collision detection. 

While receiving an ALE signal, it is possible for the continuity of the received signal to be lost 
(due to such factors as interference or fading) as indicated by failure to detect a good ALE word 
at a T,y boundary. When one or both Golay words of a received ALE word contain uncorrectable 
errors, the ALE controller shall attempt to regain word sync, with a bias in favor of words that 
arrive with the same word phase as the interrupted frame. 


If word sync is reacquired but at a new word phase, this indicates that a collision has occurred. 
The interrupted frame shall be discarded, and the interrupting signal processed as a new ALE 
frame. 


NOTE: Stations should be able to read interfering ALE signals, as they may contain useful 
(or critical) information, for which the station is “always listening.” 


A.5.5.4 One-to-many calling. 
One station may simultaneously establish a multi-way link with multiple other stations using the 
protocols described in the following subparagraphs. 


A.5.5.4.1 Slotted responses. 

The simple three-way handshake used for individual links cannot be used for one-to-many calling 
because the responses from the called stations would collide with each other. Instead, a time- 
division multiple access (TDMA) scheme is used. Each responding station shall send its 
response in an assigned or computed time slot as described later for the particular one-to-many 
protocol. 


At the end of a one-to-many call frame, the following events shall take place: 


e The calling station shall set a wait-for-response-and-tune timeout (WRTT) that shall 
trigger its acknowledgment after the last response slot time has expired. The time 
allowed is denoted Twin. The value of Twn is described later for each one-to-many 
protocol. 


e The called stations shall set their own WRTTs that bound their waiting times for an 
acknowledgment. To allow time for acquiring word sync during the leading call of the 
acknowledgment, the waiting time shall be set to Twan = Twm + 2 Try. 


e Each called station shall also set a slot wait timeout T,,; that shall trigger its response. 


e The called stations shall tune as required during the slot immediately following the end of 
the call frame, called slot 0. 


As each station’s slot wait timer expires, it shall send its response and continue to await the 
expiration of its WRTT. Should that timer expire before the start of an acknowledgment from 
the calling station, the called station shall abort the linking attempt, and return to its pre-linking 
state. 
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A.5.5.4.1.1 Slotted response frames. 

Slotted response frames shall be formatted identically to responses in the one-to-one calling 
protocol (see figure A-32), including a leading call, an optional message section, and a frame 
conclusion. A responding station shall conclude its response with TIS to accept the call, or 
TWAS to reject it. When the calling and responding addresses are one-word (as shown), slots 
are each 14 T,,, or about 1.8 seconds. 


TO TIS TO TO TIS TO TO TIS 
a) NET SAM SAM SAM JOE SAM SAM BOB eee 


Slot 1 Slot 2 


FIGURE A-32. Slotted responses. 


A.5.5.4.1.2 Slot widths. 

Unless otherwise specified, all slots shall be 14 T,, in duration, which allows response frames 
with single-word addresses to propagate to and from the other side of the globe and use 
commonly available HF transceivers and tuners. When any slot is extended, all following slots 
shall be delayed commensurately. 


e When the calling station address is longer than one word, every slot shall be extended by 
two Try (six Ty) per additional address word. 


e When a called station address is longer than one word, its slot shall be extended by one 
Try (three T,,) per additional address word. 


e Slots shall be extended by one T,,, (three Ty) for each ALE word to be sent in the 
message section of responses (including LQA CMD). 


A.5.5.4.1.3 Slot wait time formula. 
The general formula for determining the correct timing for slotted responses in nonminimum or 
nonuniform cases is as follows for a selected slot number denoted SN: 


Tswi(SN) = SN x [5 Ty +2 T, (caller) + (optional message) Tn] + Ta (caller) + 
m=SN-1 

x Ta (m) (called) 

m=1 


Where T, (caller) is the address length (an integer multiple of T,,) of the calling station, 
(optional message)Tm is an optional message section (same size for all slots), present if and only 
if requested in the call. T,(m) (called) is the address length of the station that will respond in slot 
m. (Note that the length of slot 0 is determined by using the address length of the calling 
station.) The formula for the calling station wait for net reply timeout (Twm) is 
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Twn = Tswt (NS + 1) 
where NS is the total number of slots; one is added to include slot zero. 
The formula for the called station acknowledgment timer is 
Teva =I 2 ey 


A.5.5.4.1.4 Slotted response example. 
The slotted response example is shown in figure A-33. 


Scanning Call Leading Call 


TO TO TO TIS TO TO TIS TO TO TIS 
5 NET NET | NET SAM SAM | SAM JOE SAM | SAM ]] BOB 


Slot 1 Slot 2 


FIGURE A-33. 2G ALE slotted responses. 


A.5.5.4.2 Star net calling protocol. 

A net address is assigned to a set of net member stations, as described in A.5.2.4.4. The slot 
number and address to be used by each net member are preassigned and known to all net 
members. 


A.5.5.4.2.1 Star net call. 

A star net call is identical to a one-to-one call, except that the called station address is a net 
address, as shown in figure A-34. The calling station address shall be an individual station 
address (not a net or other collective address). 


Scanning Call Leading Call 


TO | JO TO | IO TO TO Hs 
NET | NET | °° ° NET | NET NET | NET SAM 


FIGURE A-34. Net call. 


A.5.5.4.2.2 Star net response. 

When an ALE controller receives a call that is addressed to a net address that appears in its self 
address memory (see A.4.3.2), it shall process the call using the same checks and timeouts as an 
individual call (see A.5.5.3.2). If the call is acceptable, it shall respond in accordance with 


A.5.5.4.1 using its assigned net member address and slot number for the net address that was 
called. 
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A.5.5.4.2.3 Star net acknowledgment. 
A star net acknowledgment is identical to a one-to-one acknowledgment, except that the called 
station address is a net address. 


An ALE controller that has responded to a net call shall process the acknowledgment from the 
calling station in accordance with A.5.5.3.4, except that the wait-for-response timeout value shall 
be the Twan timeout from A.5.5.4.1.3. A TWAS acknowledgment from the calling station shall 
return the called ALE controller to its pre-linking state. If a TIS acknowledgment is received 
from the calling station, the called ALE controller shall enter the linked state with the calling 
station (SAM in this example), alert the operator (and network controller if present), unmute the 
speaker, and set a wait-for-activity timeout Twa. 


A.5.5.4.3 Star group calling protocol. 

The group calling protocol extends the power of one-to-many calling to ad hoc collections of 
stations that have not been preprogrammed as a net. Nothing need be known about the stations 
except their individual addresses and scanned frequencies. Because a group is not set up in 
advance, stations must be able to derive group membership and slot parameters on the fly. 
Group membership is limited as follows: 


e The total length of group member station addresses cannot exceed 12 ALE words. 


e The set of unique first address words among group members cannot exceed five words. 


A.5.5.4.3.1 Star group scanning call. 

A group address is produced by combining individual addresses of the stations that are to form 
the group. During a scanning call, only the first word(s) of addresses shall be sent, just as for 
individual or net calls. The set of unique first address words for the group members shall be sent 
repeatedly in rotation until the end of Ts.. These address words shall alternate between THRU 
and REP preambles (see figure A-35 for a sample group consisting of BOB, EDGAR, and SAM). 


THRU | REP JTHRU | REP |THRU| REP REP (end of Tsc: lic 
BOB | EDG [SAM BOB | EDG | SAM Peg Beet line} 


TO |REP |DATA | TO |DATA| TO |REP JDATA | TO |DATA |] TIS 
BOB |EDG |AR@ | SAM | UEL | BOB |EDG | AR@ | SAM |] UEL JOE 
FIGURE A-35. Group call. 


When group member addresses share a common first word, that word shall be sent only once 
during Ts:. A limit of five unique first words may be sent in rotation during Tx. 
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A.5.5.4.3.2 Star group leading call. 

During T\., the complete addresses of the prospective group members shall be sent, using TO 
preambles as usual. Up to 12 address words total are allowed for the full addresses of group 
members, so Tj, in a group call may last up to 24 T,,. Note in figure A-34 that when a TO word 
would follow another TO word, a REP preamble must be used, but when a TO follows any other 
word it shall remain a TO. 


A.5.5.4.3.3 Star group call conclusion. 
The optional message section and the conclusion of a star group call shall be in accordance with 


Po. 


A.5.5.4.3.4 Receiving a star group call. 
Slots shall be derived for group call responses by noting the order in which individual addresses 


appear in the call. 


a. When an ALE controller pauses on a channel carrying a group scanning call, it will read 
either a THRU or a REP preamble. If the address word in this first recetved word matches 
the first word of one of its individual addresses, the ALE controller shall stay to read the 
leading call. Otherwise, it shall continue to read first address words until it finds: 


e amatch with the first word of a self address, or 
e arepetition of a word it has already seen, or 


e five unique words. 


(In the latter two cases, the station is not being called and the ALE controller shall return to the 
available or linked state as appropriate.) 


b. When T,, starts, an ALE controller potentially addressed in the scanning call shall watch 
for its complete address. If found, a slot counter shall be set to 1 and incremented for each 
address that follows it. If that address is found again (as it should be, because the address list 
is repeated in Tj,), the counter shall be then reset to 1, and incremented for each following 
address as before. The number of words in each following address shall also be noted for 
use in computing Tyyt. 


c. The message section (if any) and the frame conclusion shall processed in accordance with 
A.5.5.3.2. 


In the event that an addressed ALE controller arrives on channel too late to identify the size of 
the called group, it will be unable to compute the correct Tyan. In this situation, it shall use a 
default value for Twan, which is equal to the longest possible group call of twelve one-word 
addresses. It will, however, have computed its correct slot number because to have received its 
own address it must also have received the addresses that followed that self address in the 
leading call. 
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A.5.5.4.3.5 Star group slotted responses. 
Slotted responses shall be sent and checked in accordance with A.5.5.4.1, using the derived slot 
numbers and the self address contained in the leading call. 


A.5.5.4.3.6 Star group acknowledgment. 

The acknowledgment in a group call handshake shall be addressed to any subset of the members 
originally called, and is usually limited to those whose responses were heard by the calling 
station. The leading call of the acknowledgment shall include the full addresses of the stations 
addressed, sent twice, using the same syntax as in the call (A.5.5.4.3.2). 


An ALE controller that responded to a group call shall await acknowledgment and process an 
incoming acknowledgment in accordance with A.5.5.3.4, with the following exceptions: 


e The wait-for-response timeout value shall be the Tyan timeout from A.5.5.4.1.3, not Tyr 


e Self address detection shall search through the entire leading call group address. 


An ALE controller that responded but was not named in the acknowledgment shall return to its 
pre-linking state. An ALE controller that is addressed in the acknowledgment shall proceed as 
follows: 


e A TWAS acknowledgment from the calling station shall return the called ALE controller 
to its pre-linking state. 


e Ifa TIS acknowledgment is received from the calling station, the called ALE controller 
shall enter the linked state with the calling station (SAM in this example), alert the 
operator (and network controller if present), unmute the speaker, and set a wait-for- 
activity timeout Twa. 


A.5.5.4.3.7 Star group call example. 

In the example group call in figure A-35, SAMUEL will respond in slot 1, with Tyyt = 14 Ty (the 
one-word address JOE causes slot 0 to be 14 T,,). EDGAR will respond in slot 2, with Ts; = 14 
+17 Ty =31 Ty (slot 1 is 17 T,, because of SAMUEL’s two-word address). BOB will respond 
in slot 3, with Ts: =48 Ty. JOE will send an acknowledgment after 62 T,. 


A.5.5.4.3.8 Multiple self addresses in group call. 
If a station is addressed multiple times in a group call, even by different addresses, it shall 
properly respond to at least one address. 


NOTE: The fact that the called station has multiple addresses may not be known to the 
caller. In some cases, it would be confusing or inappropriate to respond to one but not 
another address. Redundant calling address conflicts can be resolved after successful linking, 
if there is a problem. 
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A.5.5.4.4 Allcall protocol. 

An AllCall requests all stations hearing it to stop and listen, but not respond. The AllCall special 
address structure(s) (see A.5.2.4.7) shall be the exclusive member(s) of the scanning call and the 
leading call, and shall not be used in any other address field or any other part of the handshake. 
The global AllCall address shall appear only in TO words. Selective AllCalls with more than 
one selective AllCall address, however, shall be sent using group addressing, using THRU during 
the scanning call and TO during the leading call. 


An AllCall pertains to an ALE controller when it is a global AllCall, or when a selective AllCall 
specifies a character that matches the last character of any self address assigned to that station. 
Upon receipt of a pertinent AllCall, an ALE controller shall temporarily stop scanning and listen 
for a preset limited time, Tec max. 


e Ifa message section or frame conclusion does not arrive within Tec max, the controller 
shall automatically resume scanning. 


e Ifa quick-ID (an address beginning with a FROM word immediately after the calling 
cycle) arrives, the pause for the message section shall be extended for no more than five 
words (5 T,), and if a CMD does not arrive, the controller shall resume scanning. 


e Ifa message arrives (indicated by receipt of a CMD), the controller shall pause for a 
preset limited time, Tm max to read the message. If the frame conclusion does not arrive 
within Ti max, the controller shall automatically resume scanning. If a conclusion arrives 
(indicated by receipt of a TIS or TWAS), the controller shall pause (for a preset limited 
time, Tx max) to read the caller’s address. If the end of the signal does not arrive within T, 
max, the controller shall automatically resume scanning. 


If a pertinent AllCall frame is successfully received and is concluded with a TIS, the controller 
shall enter the linked state, alert the operator, unmute its speaker and start a wait-for-activity 
timeout. If an AllCall is successfully received with a TWAS conclusion, the called controller 
shall automatically resume scanning and not respond (unless otherwise directed by the operator 
or controller). 


If a station receiving an AllCall desires to attempt to link with the calling station, the operator 
may initiate a handshake within the pause after a TIS conclusion. Note that in all handshakes 
(the initial AllCall does not constitute a handshake), the AllCall address shall not be used. To 
minimize possible adverse effects resulting from overuse or abuse of AllCalls, controllers shall 
have the capability to ignore AllCalls. Normally AllCall processing should be enabled. 


A.5.5.4.5 AnyCall protocol. 

An AnyCall is similar to an AllCall, but it instead requests responses. Use of the AnyCall special 
address structures is identical to that for the AllCall special address structures. Upon receipt of a 
pertinent AnyCall, an ALE controller shall temporarily stop scanning and examine the call 
identically to the procedure for AllCalls, including the Tec max, Tm max, and Tx max limits. 
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If the AnyCall is successfully received, and is concluded with TIS, the controller shall enter the 
linking state and automatically generate a slotted response in accordance with A.5.5.4.1 and the 
following special procedure: 


e Because neither preprogrammed nor derived slot data are available, the controller shall 
randomly select a slot number, | through 16. 


e Each slot shall be 20 T,, (2613.33...ms) wide, unless the calling station requests LQA 
responses, in which case the slots shall expand by 3 Ty to 23 Ty to accommodate the 
CMD LQA message section. 


e The controller shall compute values for Tsy: and Twan using this slot width and its random 
slot number. 


e Slot 0 shall be used for tuning, as usual for slotted response protocols. 


e Upon expiration of its T;,; timeout, the controller shall send a standard star net response 
consisting of TO (with the address of the caller) and TIS (with the address of the 
responder), with the LQA CMD included if requested. Responders shall use a self 
address no longer than five words minus twice the caller address length. (For example, if 
the caller address is two words, the responder shall use a one-word address.) The 
AnyCall special address shall not be sent. 


In this protocol, collisions are expected and tolerated. The station sending the AnyCall shall 
attempt to read the best response in each slot. 


Upon receipt of the slotted responses, the calling station shall transmit an ACK to any subset of 
stations whose responses were read, using an individual or group address. The AnyCall special 
address shall not be used in the acknowledgment. The caller selects the conclusion of its ACK 
to either maintain the link for additional interoperation and traffic with the responders (TIS), or 
return everyone to scan (TWAS), as appropriate to the caller’s original purpose. 


An ALE controller that responded to an AnyCall shall await and process the acknowledgment in 
accordance with A.5.5.4.3.6. 


To minimize possible adverse effects resulting from overuse or abuse of AnyCalls, controllers 
shall have the capability to ignore AnyCalls. Normally AnyCall processing should be enabled. 


A.5.5.4.6 Wildcard calling protocol. 

Wildcard addresses shall be the exclusive members of a calling cycle in a call, and shall not be 
used in any other address sequence in the ALE frame or handshake. The span (number of cases 
possible) of the wildcard(s) used should be minimized to only the essential needs of the user(s). 


Calls to wildcard addresses that conclude with TWAS shall be processed identically to the 
AllCall protocol. 
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Responses to wildcard calls that conclude with TIS shall be sent in pseudorandomly-selected 
slots in accordance with the AnyCall protocol. 


As in both the AllCall and AnyCall, the controller shall be programmable to ignore wildcard 
calls, but wildcard call processing should normally be enabled. 


A.5.6. ALE control functions (CMDs other than AMD, DTM, and DBM). 
In addition to automatically establishing links, stations shall have the capability to transfer 


information within the orderwire, or message, section of the frame. This section describes these 


messages, including data, control, error checking, networking, and special purpose functions. 
Table A-XVI provides a summary of the CMD functions. 


NOTE: For critical orderwire messages that require increased protection from interference 


and noise, several ALE techniques are available. Any message may be specially encoded 
off-line and then transmitted using the full 128 ASCII CMD data DTM mode (which also 
accepts random data bits). Larger blocks of information may be Golay FEC coded and 
deeply interleaved using the CMD DBM mode. Both modes have an automatic repeat 


request (ARQ) error-control capability. Integrity of the data may be ensured using the CMD 


cyclic redundancy check (CRC) mode (see A.5.6.1). In addition, once a link has been 
established, totally separate equipment, such as heavily coded and robust modems, may be 
switched onto the rf link in the normal circuit (traffic-bearing) mode. 
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TABLE A-XVI. Summary of CMD functions. 


First Character Second Character Function 
Any of the extended-64 character set AMD 
1100000 Advanced LQA 
1100001 LQA 
1100010 Data block analysis 
1100011 Channels 
1100100 DTM 
1100110 Frequency 
1101101 Mode selection commands 
1100001 Analog port Selection 
1100011 Crypto negotiation 
1100100 Data port selection 
1101110 Modem negotiation 
1110001 Digital squelch 
1101110 Noise report 
1110000 Power control 
1110010 LQA report 
1110100 Scheduling commands 
1100001 Adjust slot width 
1100010 Station busy 
1100011 Channel busy 
1100100 Set dwell time 
1101000 Halt and wait 
1101100 Contact later 
1101101 Meet me 
1101110 Poll operator (default NAK) 
1101111 Request operator ACK 
1110000 Schedule periodic function 
1110001 Quiet contact 
1110010 Respond and wait 
1110011 Set sounding interval 
1110100 Tune and wait 
1110111 Set slot width 
1111000 Do not respond 
1111001 Year and date 
1111010 Zulu time 
1100011 Capabilities 
1110011 Versions 
1111000 CRC* 
1111001 CRC* 
1111010 CRC* 
1111011 CRC* 
1111100 User-unique functions 
1111110 Time exchange 


1110110 


a 
b 
c 
d 
h 
1 
m 
n 
fC) 
Pp 
q 
r 
s 
t 
w 
Xx 
y 
Zz 
c 
s 


*(16-bit CRC overflows into the two least-significant bits of the first two character) 


141 


MIL-STD-188-141B 
APPENDIX A 


A.5.6.1 CRC. 
This special error-checking function is available to provide data integrity assurance for any form 
of message in an ALE call. 


NOTE: The CRC function is optional, but mandatory when used with the DTM or DBM 
modes. 


The 16-bit frame check sequence (FCS) and method as specified by FED-STD 1003 shall be 
used herein. The FCS provides a probability of undetected error of pia independent of the 
number of bits checked. The generator polynomial is 


x64 x4 x7 +1 
and the sixteen FCS bits are designated 
(MSB) X"*, X'*, X83, X!*_X!, X° (LSB) 


The ALE CRC is employed two ways: within the DTM data words, and following the DBM data 
field, described in paragraphs A.5.7.3 and A.5.7.4, respectively. The first, and the standard, 
usages are described in this section. 


The CMD CRC word shall be constructed as shown in table A-XVII. The preamble shall be 
CMD (110) in bits P3 through P1 (W1 through W3). The first character shall be “x” (1111000), 
“vy? (1111001), “z” (1111010), or “{” (1111011) in bits C1-7 through C1-1 (W4 through W10). 
Note that four identifying characters result from FCS bits X'° and X'* which occupy C1-2 and 
C1-1 (W9 and W10) in the first character field respectively. The conversion of FCS bits to and 
from ALE CRC format bits shall be as described in table A-XVII where X'° through X° 
correspond to W9 through W24. 


The CMD CRC message should normally appear at the end of the message section of a 
transmission, but it may be inserted within the message section (but not within the message being 
checked) any number of times for any number of separately checked messages, and at any point 
except the first word (except as noted below). The CRC analysis shall be performed on all ALE 
words in the message section that precede the CMD CRC word bearing the FCS information, and 
which are bounded by the end of the calling cycle, or the previous CMD CRC word, whichever is 
closest. The selected ALE words shall be analyzed in their non-redundant and unencoded (or 
FEC decoded) basic ALE word (24-bit) form in the bit sequence (MSB) W1, W2, W3, W4...W24 
(LSB), followed by the unencoded bits W1 through W24 from the next word sent (or received), 
followed by the bits of the next word, until the first CMD CRC is inserted (or found). Therefore, 
each CMD CRC inserted and sent in the message section ensures the data integrity of all the bits 
in the previous checked ALE words, including their preambles. If it is necessary to check the 
ALE words in the calling cycle (TO) preceding the message section, an optional calling cycle 


142 


MIL-STD-188-141B 
APPENDIX A 


CMD CRC shall be used as the calling cycle terminator (first FROM or CMD), shall therefore 
appear first in the message section, and shall analyze the calling cycle words in their simplest 
(T,), nonredundant and nonrotated form. If it is necessary to check the words in a conclusion 
(TIS or TWAS), an optional conclusion CRC shall directly precede the conclusion portion of the 
call, shall be at the end of the message section, and shall itself be directly preceded by a separate 
CMD CRC (which may be used to check the message section or calling cycle, as described 
herein). Stations shall perform CRC analysis on all received ALE transmissions and shall be 
prepared to compare analytical FCS values with any CMD CRC words which may be received. 
If a CRC FCS comparison fails, an ARC (or operator initiated) or other appropriate procedure 
may be used to correct the message. 
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TABLE A-XVII. Cyclic redundancy check structure. 


CRC bits Word bits 
CMD preamble 


First characters 


XYZ, { 


Nu 


o 


NOTES: 


1. CMD CRC first character is one of four, “x” (1111000), “y” (1111001), “z” 


(11111010), or “{” (1111011), depending on CRC bits x '* and x", which are also C1-2 
and C1-1, respectively. 


2. “x? indicates FCS bits. 


A.5.6.2 Power control (optional). 

The power control orderwire function is used to advise parties to a link that they should raise or 
lower their rf power for optimum system performance. The power control CMD word format 
shall be as shown in figure A-36. The KP control bits shall be used as shown in table XVIII. 
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al ae ve SOT ST 


1110000 
(‘p’: power control) KP1-3 Power | (reserved) 


FIGURE A-36. Power control CMD format. 


TABLE A-XVIII. Power control CMD bits (KP1-3). 
Meaning 


KP3 (MSB) Request to adjust power 
Report of current power level 


KP, Relative Power (in dB) 


Absolute Power (in dBW) 
Relative Power (dB) is positive 
KP, (LSB) Relative Power (dB) is negative 


The procedure shall be: 


a. When KP3 is set to 1, the power control command is a request to adjust the power from 
the transmitter. If KP» is 1, the adjustment is relative to the current operating power, 1.e., to 
raise (KP; = 1) or lower (KP; = 0) power by the number of dB indicated in the relative power 
field. If KP2 is 0, the requested power is specified as an absolute power in dBW. 


b. When KP3 is set to 0, the power control command reports the current power output of the 
transmitter, in dB relative to nominal power if KP» is 1, or in absolute dBW if KP» is 0. 


c. KP, shall be set to 0 whenever KP> is 0. 


d. Normally, a station receiving a power control request (KP3= 1) should approximate the 
requested effect as closely as possible, and respond with a power report (KP3 = 0) indicating 
the result of its power adjustment. 


A.5.6.3 Channel related functions. 
The channel related functions are defined in the following subparagraphs. 


A.5.6.3.1 Channel designation. 

When two or more stations need to explicitly refer to channels or frequencies other than the 
one(s) in use for a link, the following encodings shall be used. A frequency is designated using 
binary-coded-decimal (BCD). The standard frequency designator is a five-digit string (20 bits), 
in which the first digit is the 10 megahertz (MHz) digit, followed by 1 MHz, 100 kilohertz (kHz), 
10 kHz, and 1 kHz digits. A frequency designator is normally used to indicate an absolute 
frequency. When a bit in the command associated with a frequency designator indicates that a 
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frequency offset is specified instead, the command shall also contain a bit to select either a 
positive or a negative frequency offset. 


A.5.6.3.2 Frequency designation. 

A channel differs from a frequency in that a channel is a logical entity that implies not only a 
frequency (or two frequencies for a full-duplex channel), but also various operating mode 
characteristics, as defined in A.4.3.1. As in the case of frequency designators, channels may be 
specified either absolutely or relatively. In either case, a 7-bit binary integer shall be used that is 
interpreted as an unsigned integer in the range 0 through 127. Bits in the associated command 
shall indicate whether the channel designator represents an absolute channel number, a positive 
offset, or a negative offset. 


a. The frequency select CMD word shall be formatted as shown in figure A-37. A frequency 
designator (in accordance with A.5.6.3.1) is sent ina DATA word immediately following the 
frequency select CMD; bit W4 of this DATA word shall be set to 0, as shown. 


FIGURE A-37. Frequency select CMD format. 


b. The 100 Hz and 10 Hz fields in the frequency select CMD word contain BCD digits that 
extend the precision of the standard frequency designator. These digits shall be set to 0 
except when it is necessary to specify a frequency that is not an even multiple of 1 kHz (e.g., 
when many narrowband modem channels are allocated within a 3 kHz voice channel). 


c. The control field shall be set to 000000 to specify a frequency absolutely, to 100000 to 
specify a positive offset, or to 110000 to specify a negative offset. 


d. A station receiving a frequency select CMD word shall make whatever response is 
required by an active protocol on the indicated frequency. 
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A.5.6.3.3 Full-duplex independent link establishment (optional). 

Full duplex independent link establishment is an optional feature; however, if this option is 
selected the transmit and receive frequencies for use on a link shall be negotiated independently 
as follows: 


a. The caller shall select a frequency believed to be propagating to the distant station (the 
prospective responder) and places a call on that frequency. The caller embeds a frequency 
select CMD word in the call to ask the responder to respond on a frequency chosen for good 
responder-to-caller propagation (probably from sounding data in the caller’s LQA matrix). 


b. If the responder hears the call, it shall respond on the second frequency, asking the caller 
to switch to a better caller-to-responder frequency by embedding a frequency select CMD 
word in its response (also based upon sounding data). 


c. The caller shall send an acknowledgment on the frequency chosen by the responder (the 
original frequency by default), and the full duplex independent link is established. 


A.5.6.3.4 LQA polling (optional). 
See MIL-STD-187-721. 


A.5.6.3.5 LQA reporting (optional). 
See MIL-STD-187-721. 


A.5.6.3.6 LQA scan with linking (optional). 
See MIL-STD-187-721. 


A.5.6.3.7 Advanced LQA (optional). 
See MIL-STD-187-721. 


A.5.6.4 Time-related functions. 


A.5.6.4.1 Tune and wait. 

The CMD tune and wait special control function directs the receiving station(s) to perform the 
initial parts of the handshake, up through tune-up, and wait on channel for further instructions 
during the specified time limit. The time limit timer is essentially the WRTT as used in net 
slotted responses where its value Twn is set by the timing information in the special control 
instruction, and it starts from the detected end of the call. The CMD tune and wait instruction 
shall suppress any normal or preset responses. Except for the tune-up itself, the receiving 
station(s) shall make no additional emissions, and they shall quit the channel and resume scan if 
no further instructions are received. 


NOTE: This special control function enables very slow tuning stations, or stations that must 
wait for manual operator interaction, to effectively interface with automated networks. 
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The CMD tune and wait shall be constructed as follows and as shown in table A-XIX. The 
preamble shall be CMD (110) in bits P3 through P1 (W1 through W3). The first character (C1) 
shall be “tt” (1110100) in bits C1-7 through C1-1 (W4 through W10) and “t” (1110100) in bits 
C2-7 through C2-1 (W11 through W17), for “time, tune-up.” The “T” time bits TB7 through 
TB1 (W18 through W24) shall be values selected from table A-XX, and limited as shown in 
table A-XXI. The lowest value (00000) shall cause the tuning to be performed immediately, with 
zero waiting time, resulting in immediate return to normal scan after tuning. 


A.5.6.4.2 Scheduling commands. 

These special control functions permit the manipulation of timing in the ALE system. They are 
based on the standard “‘T” time values, presented in table A-XX, which have the following ranges 
based on exact multiples of T,, (130.66...ms) or T,y (392 ms). 


e (0 to 4 seconds in 1/8 second (Ty) increments 


e (0 to 36 seconds in | second (3 T,y) increments 
e (0 to 31 minutes in | minute (153 T,,) increments 


e (0 to 29 hours in | hour (9184 T,.) increments 


There are several specific functions that utilize these special timing controls. All shall use the 
CMD (110) preamble in bits P3 through P1 (W1 through W3). The first character is “t” 
(1110100) for “time.” The second character indicates the function as shown in table A-XXI. The 
basic structure is the same as in table A-XIX. 


148 


MIL-STD-188-141B 
APPENDIX A 


TABLE A-XIX. Tune and wait structure. 
| Tune and Wait Bits | Word Bits 


CMD 
Preamble 


First 
Character 
6 sf i ° 


Second 
Character 
© i i ° 


Time Bits 
aa ce 


CMD tune and wait first two characters are “t” (1110100) and “‘t’” (1110100) for “time tune- 


up.” 
Time bits TB7 through TB1 from table A-XX. 
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TABLE A-XX. Time values. 


MULTIPLIER: MSBs 

MSB Approximate | Approximate 

TB7 increment increment range 

(W18) of “T” 
values 


[OT 130.66. . ms 1/8 second 


seconds 
153 T, 59.976 sec 1 minute 0-31 
Fa Fc cc 


9184 T,,, 60.002min 0 - 29 hours 


INDEX: Least significant Bits (LSBs) 
TBS TB4 TB3 TB2 LBS INDEX 
(W20) | (W211) | (W22) | (W23) | TBI VALUE 
(W24) 


a 7 
i i 


The minimum value “0” (TB = 0000000) is interpreted as “do immediately” if a delay, or “zero size” if a 
time width, as specified in usage. 

The maximum value “127” (TB = 1111111) 1s interpreted as “do it at time or date following,” as specified in 
next CMD. 

The next maximum value “126” (TB = 1111110) is interpreted as “indefinite time,” unlimited except by 
other CMD or timeout protocol. 
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TABLE A-XXI. Time-related CMD functions. 


First Second 
Identification Characte Character Function 


Adjust Slot Width “a” (1100001) Add T to width of all slots for this response. 
TB=0, normal. TB7=0 as 36 second limit. 


Halt and Wait “h” (1101000) Stop scan on channel, do not tune or respond, 
wait T for instruction; quit and resume scan if 
nothing. TB=0, quit after call. TB7=0 as 36 
second limit. 


Operator NAK “n” (1101110) Same as “t,o” operator ACK, except that at T, if 
no input, automatic tune-up and respond NAK 
(TIS), in slots if any. TB=0, NAK now. 


Operator ACK “o” (1101111) Stop scan, alert operator to manually input ACK 
(or NAK), which causes tune-up (if needed) and 
ACK response TWAS, or TIS; if no input by 
operator by T, simply quit. TB=0, ACK now. 
TB7=0 as 36 second time limit. TB=1111111, 
do at date/time following. 


Respond and Wait “r (1110010) Stop scan, tune-up and respond as normal, wait T 
for instructions, quit and resume scan if nothing. 
TB=0, quit after response. TB7=0 as 36 second 
limit. TB=1111111, do at date/time following. 


Tune and Wait “t? (1110100) Stop scan, tune-up, do not respond, wait T for 
Instructions, quit and resume scan if nothing. 
TB=0, quit after tune-up. TB7=0 as 36 second 
limit. 


Width of Slots “w? (1110111) Set all slots to T wide for this response. TB=0, 
no responses. TB7=0 as 36 second limit. 


Preamble is CMD (110). 

First character is “t” (1110100) for all. 

Third-character field is binary bits TB7 through TB1 (W18 through W24), designating a time 
interval “T” as a standard value in table A-XX. 

When the optional UUF is implemented, the STAY command function is required. 

This second ASCII character will vary, depending on the resulting binary value. 


A.5.6.4.3 Time exchange word formats. 
The mandatory time protocols employ the following three types of ALE words: (1) command 


words, (2) coarse time words, and, (3) authentication words, in the formats listed below. 
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A.5.6.4.3.1 Command words. 

Time exchange command words Time Is and Time Request that are used to request and to 
provide time of day (TOD) data, shall be formatted as shown in figure A-38. The three most- 
significant bits (W1-3) shall contain the standard CMD preamble (110). The next seven bits 
(W4-10) shall contain the ASCII character ‘~’(1111110), indicating the magnitude of time 
uncertainty at the sending station in accordance with A.5.6.4.6. 


A.5.6.4.3.2 Time Is command. 

The Time Is command word carries the fine time current at the sending station as of the start of 
transmission of the word following the Time Is command word, and is used in protected time 
requests and all responses. In a Time Is command word, the seconds field shall be set to the 
current number of seconds elapsed in the current minute intervals which have elapsed in the 
current second (0-24). The time quality shall reflect the sum of the uncertainty of the local time 
and the uncertainty of the time of transmission of the Time Is command, in accordance with table 
A-XXII and A.5.6.4.6. When a protocol requires transmission of the Time Is command word, 
but no time value is available, a NULL Time Is command word shall be sent, containing a time 
quality of 7 and the seconds and ticks fields both set to all 1s. 


A.5.6.4.3.3 Time Request command. 

The Time Request command word shall be used to request time when no local time value is 
available, and is used only in non-protected transmissions. In a Time Request command word, 
time quality shall be set to 7, the seconds field to all 1s, and the ticks field set to 30 (11110). 


A.5.6.4.3.4 Other encodings. 
All encodings of the seconds and ticks fields not specified here are reserved, and shall not be 
used until standardized. 


A.5.6.4.4 Coarse time word. 
Coarse time words shall be formatted as shown in figure A-39, and shall contain the coarse time 
current as of the beginning of that word. 
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Time Service 
Example 
Date=8 May 
Time=15:57:34:12 
Time Quality=4 


ay Time aa ar 40 ms ae 
$e 


1111110 100010 00011 


“TIME IS” 
Command 


FIGURE A-38. Time exchange CMD word. 


A.5.6.4.5 Authentication word. 

Authentication words, formatted as shown in figure A-39, shall be used to authenticate the times 
exchanged using the time protocols. The 21-bit authenticator shall be generated by the sender as 
follows: 


a. All 24-bit words in the time exchange message preceding the authentication word 
(starting with the Time Is or Time Request command word which begins the message) shall 
be exclusive-or’d. 


b. If the message to be authenticated is in response to a previous time exchange message, the 
authenticator from that message shall be exclusive-or’d with the result of (1). 


c. The 21 least significant bits of the final result shall be used as the authenticator. 


A.5.6.4.6 Time quality. 

Every time exchange command word transmitted shall report the current uncertainty in TOD at 
the sending station, whether or not time is transmitted in the command word. The codes listed in 
table A-XXII shall be employed for this purpose. The time uncertainty windows on the table are 
upper bounds on total uncertainty (with respect to coordinated universal time). 
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TABLE A-XXII. Time quality. 
as es ee ee 


none 


NOTE: Time quality “0” shall be used only by UTC time standard 
stations. 


Time Service 
Example 


Date = 8 May 
Time = 15:57:34:12 


Time Quality = 4 


4 5 


i 
| Month | Day | Minute 
0101 01000 011101111101 


Coarse Time Word 
21 


| Authenticator 
110101110011111111110 


Authenticator Word 
(over CMD and Coarse Time 
Words) 


FIGURE A-39. Coarse time and authentication words. 


For example, an uncertainty of +6 seconds is 12 seconds total and requires a transmitted time 
quality value of 6. Stations shall power up from a cold start with a time quality of 7. Time 
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uncertainty is initialized when time is entered (see B.5.2.2.1) and shall be maintained thereafter 
as follows: 


a. The uncertainty increases at a rate set by oscillator stability (e.g., 72 ms per hour with a 
+10 parts per million (ppm) time base). 


b. Until the uncertainty is reduced upon the acceptance of time with less uncertainty from an 
external source after which the uncertainty resumes increasing at the above rate. 


A station accepting time from another station shall add its own uncertainty due to processing and 
propagation delays to determine its new internal time uncertainty. For example, if a station 
receives time of quality 2, it adds to the received uncertainty of 100 ms (+50 ms) its own 
processing delay uncertainty of, say +100 ms, and a propagation delay bound of +35 ms, to 
obtain a new time uncertainty of +185 ms, or 370 ms total, for a time quality of 3. With a+10 
ppm time source, this uncertainty window would grow by 72 ms per hour, so after two hours, the 
uncertainty becomes 514 ms, and the time quality has dropped to 4. If a low-power clock is used 
to maintain time while the rest of the unit is powered off, the quality of this clock shall be used to 
assign time quality upon resumption of normal operation. For example, if the backup clock 
maintains an accuracy of +100 ppm under the conditions expected while the station is powered 
off, the time uncertainty window shall be increased by 17 seconds per day. Therefore, such a 
radio, which has been powered-off for much over three days, shall not be presumed to retain even 
coarse sync, despite its backup clock, and may require manual entry of time. 


A.5.6.5 Mode control functions (optional). 

If any of these features are selected, however, they shall be implemented in accordance with this 
standard. Many of the advanced features of an ALE controller are “modal” in the sense that 
when a particular option setting is selected, that selection remains in effect until changed or reset 
by some protocol event. The mode control CMD is used to select many of these operating 
modes, as described in the following paragraphs. The CMD word shall be formatted as shown in 
figure A-40. The first character shall be ‘m’ to identify the mode control command; the second 
character identifies the type of mode selection being made; the remaining bits specify the new 
setting for that mode. 


1101101 


(‘m’: mode control) Mode ID | Mode Selection 


FIGURE A-40. Mode control CMD format. 


A.5.6.5.1 Modem negotiation and handoff. 
An ALE data link can be used to negotiate a modem to be used for data traffic by exchanging 


modem negotiation messages. A modem negotiation message shall contain one modem selection 
command. 
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NOTE: This function may best be implemented in a high frequency node controller (HFNC) 
to avoid retrofit to existing ALE controllers, and for the greater flexibility inherent in 
network management information bases. 


A.5.6.5.1.1 Modem selection CMD. 

The modem selection CMD word shall be formatted as shown in figure A-41, and may be 
followed by one or more DATA words, as described below. The defined modem codes are listed 
in table A-X XIII. Codes not defined are reserved, and shall not be used until standardized. 


1101101 1101110 


(‘m’: mode control) (‘n’: modem select) Modem Code 


FIGURE A-41. Modem selection CMD format. 


A.5.6.5.1.2 Modem negotiating. 
Modem negotiating shall employ modem negotiation messages in the following protocol: 


a. The station initiating the negotiation will send a modem selection CMD word containing 
the code of the modem it wants to use. 


b. The responding station(s) may either accept this modem selection or suggest alternatives. 
A station accepting a suggested modem shall send a modem selection CMD word containing 
the code of that modem. 


c. A station may negotiate by sending a modem selection CMD word containing all 1s in the 
modem code field, followed by one or more DATA words containing the codes of one or 
more suggested modems. Modem codes shall be listed in order of preference in the DATA 
word(s). Unused positions in the DATA word(s) shall be filled with the all 1s code. 


d. The negotiation is concluded when the most recent modem negotiation message from all 
participating stations contains an identical modem selection CMD word with the same 
modem code (not all 1s). When this occurs, the station that initiated the negotiation will 
normally begin sending traffic using the selected modem. 
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TABLE A-XXIII. Modem codes. 


Code 


1111111 Reserved to indicate no modem code. (All others reserved until 
defined) 


A.5.6.5.2 Crypto negotiation and handoff. 
When crypto negotiation and handoff are required, the following applies: 


a. An ALE data link can also be used to negotiate an encryption device to be used for voice 
or data traffic by exchanging crypto negotiation messages. The crypto selection CMD word 
is formatted as shown in figure A-42. The defined crypto codes are listed in table A-XXIV. 
Codes not defined are reserved, and shall not be used until standardized. 


NOTE: This function may best be implemented in an HFNC to avoid retrofit to existing 
ALE controllers, and for the greater flexibility inherent in network management information 
bases. 
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1101101 1100011 


(‘m’: mode control) (‘c’: crypto select) Crypto Code 


FIGURE A-42. Crypto selection CMD format. 


TABLE A-XXIV. Crypto codes. 


0000000 No encryption 
1111111 Reserved to indicate no crypto code 
(All others reserved until defined) 


b. Crypto negotiation shall employ crypto negotiation messages in the protocol described 
above for modem negotiation. 


A.5.6.6 Capabilities reporting functions. 


A.5.6.6.1 Version CMD (mandatory). 

The version CMD function is used to request ALE controller version identification. The first 
character is ‘v’ to indicate the version family of ALE CMD word functions. The second 
character shall be set to ‘s’ to select a summary report. 


NOTE: The capabilities function in A.5.6.6.2 is a variant of this function that provides more 
detailed information. 


a. The response to a version CMD is a printable ASCII message in manufacturer-specific 
format that indicates a manufacturers’ identification, the version(s) of hardware, operating 
firmware and software, and/or management firmware and software of the responding ALE 
controller, as requested by control bits KVC-.3 of the version CMD format (see figure A-43 
and table A- XXV). 


1110110 1110011 Comps | Formats 
(‘v’: version CMD) (‘s’: summary) (KVC) | (KVF) 


FIGURE A-43. Version CMD format. 
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TABLE A-XXV. Component selection. 


Component whose version is requested when bit set to 1 
KVC3 (MSB) ALE controller hardware 


KVC2 ALE controller operating firmware 
KVC1 (LSB) ALE controller network management firmware (i.e., HNMP) 


b. The requesting station specifies acceptable formats for the response in control bits KVF1-4 
in accordance with table A-XXVI. A controller responding to a version function shall 
attempt to maximize the utility of its response and: 


(1) Shall report the version(s) of all of the components requested by the KVC control bits 
that are present in the controller. 


(2) Shall use the ALE message format that represents the highest level of mutual 
capability of itself and the requesting station by comparing the message types that it 
can generate with those desired by the requesting station, and selecting the message 


type in the intersection of these two sets that correspond to the highest-numbered 
KFV bit. 


TABLE A-XXVI. Format selection. 


Reporting format desired when bit set to 1 
KVF4 (MSB) Reserved (always set to 0) 
KVF3 DBM 


KVEF2 DTM 
KVF1 (LSB) AMD Message 


A.5.6.6.2 Capabilities function. (mandatory). 

The capabilities function is used to obtain a compact representation of the features available in a 
remote ALE controller. This function uses a variant of the version CMD word, as shown in 
figures A-44 and A-45. 


A.5.6.6.2.1 Capabilities query. 
The capabilities query, shown in figure A-44, consists of a single ALE CMD word. The second 
character position shall be set to ‘c’ to select a full capabilities report (rather than a summary as 


in the version CMD). The third character position shall be set to ‘q’ in a capabilities query to 
request a capabilities report. 
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1110110 1100011 1110001 


(‘v’: version CMD) _ | (‘c’: capability) (‘q’: query) 


FIGURE A-44. Capabilities query CMD format. 


A.5.6.6.2.2 Capabilities report CMD. 
The capabilities report shall consist of a CMD word followed by five DATA words, as shown in 


figure A-45. The second character position of the capabilities report CMD word shall be set to 
‘c’ and the third character position shall be set to ‘r’. (The DATA preamble in the second and 
fourth DATA words shall be replaced by REP for transmission, as required by the ALE protocol). 


CMD 1110110 1100011 1110010 
(‘v’: version CMD) (‘c’: capability) (‘r’: report) 


a ae ee a a 
air a 
(SR1-s) (CS 1-8) (TT 1-8) 


ae a Ss es ee 
(LPT}-6) (VAP}.7) (ALQA1-8) 
ee Aes (a ee eee eee 
aa 
(OW1-8) 
DATA Scheduling 
(SCH}.21) 


FIGURE A-45. Capabilities report CMD and DATA format. 


A.5.6.6.2.3 Data format. 

The format of the DATA words in a capabilities report is constant, regardless of the capabilities 
reported, to simplify the software that implements the capabilities command. The data fields of 
the capabilities report shall be encoded in accordance with tables A-XXVII, A-X XVIII, and A- 
XXIX. The values encoded shall represent the current operational capabilities of the responding 
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ALE controller, i.e., the timing or functions currently programmed. All timing fields shall be 
encoded as unsigned integers. 


TABLE A-XXVII. Capabilities report data fields (ALE timing). 


Parameter from 
Group Field Value Units table A-XV “Timing” 


ALE Timing 


Channels/s 
100 ms 
100 ms 
logo s 


Scan rate 

Chan. scanned 

Max tune time 
Turnaround time 
Activity timeout Listen 
time Is 


* T\a=log2 n where n is the number of seconds of no detected activity before timeout. 


TABLE A-XXVIII. Capabilities report data fields (mode settings). 


Accepting ANY calls 
Accepting AMD 2msgs 


Accepting DTM msgs 
Accepting DBM msgs 
DTM capabilities 


188-141 (AnyCalls) 

188-141 (AMD mode) 
188-141 (DTM mode) 
188-141 (DBM mode) 
188-141 (DTM mode) 
188-141 (DBM mode) 


ALE VAP, (MSB)_ | Accepting ALL calls 188-141 (Allcalls) 
Protocols VAP.6 

VAP; 

VAP, 

VAP; 

VAP» 

VAP, (LSB) 


DBM capabilities 

Capable of other LP 
Capable of AL-4 LP 
Capable of AL-3 LP 
Capable of AL-2 LP 
Capable of AL-1 LP 


188-141 Appendix B 
188-141 Appendix B 
188-141 Appendix B 
188-141 Appendix B 


LP Levels LPL; (MSB) 
LPL, 
LPL; 
LPL, 
LPL, (LSB) 


Time LPT, (MSB) 
Exchange 


Acting as time server 188-141 (Time service response, Time service 
response (non-protected) 
188-141 (Active time acquisition (protected), 
Active time acquisition (non-protected) 
188-141 (Passive time acquisition) 
188-141 (Time broadcast) 

(not yet standardized) 

(not yet standardized) 


LPT; Active time acq. enable 


LPT, Passive time acq. enable 
LPT; Will send time broadcasts 
LPT, Time iteration capable 
LPT, (LSB) Precision time capable 
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TABLE A-XXIX. Capabilities report data field (feature capabilities). 


Group Bit Set to 1 iff Feature Cross Ref: MIL-STD (paragraph) 
Implemented 


Polling PP; (MSB) Full Net Poll 187-721 (Full Net Poll) 
PP, Full Group Poll 187-721 (Full Group Poll) 
PP; Channel Scan CMD 187-721 (Two Station- Multiple Channel 
Polling) 
PP, LQA Report 187-721 (LQA Report Protocol) 


PP, (LSB) Local Noise Report 188-141 (Local Noise Report) 


ALQA ALQAs (MSB) _ | Reserved (always set to 0) 
ALQA, ALQA SINAD 187-721 (SINAD and PBER) 
ALQAg ALQA PBER 187-721 (SINAD and PBER) 
ALQA; ALQA AI 187-721 (Articulation Index) 
ALQA, ALQA SD 187-721 (Spectral Distortion) 
ALQA; ALQA EFI 187-721 (Error-free Interval) 


ALQA, ALQA AVQ 187-721 (Achievable Voice Quality) 
ALQA, (LSB) ALQA ADC 187-721 (Available Data Capacity) 


Orderwire | OWs: (MSB) Frequency Select CMD 187-721 (Frequency Select Command) 
Ow, Channel Select CMD (not yet standardized) 
Modem Negotiation 188-141 (Modem Negotiation and 
Handoff) 
Crypto Negotiation 188-141 (Crypto Negotiation and handoff) 
Analog Port Selection 187-721 (Analog Port Selection) 


Data Port selection 187-721 (Data Port Selection) 
Digital Squelch 187-721 (Digital Squelch) 
OW, (LSB) Power Control 188-141 (Power Control) 


Scheduling | SCH); (MSB) Reserved (always set to 0) 
SCH Adjust Slot Width 187-721 (Adjust Slot Width) 
SCH» Station Busy 187-721 (Station Busy) 
SCHis Channel Busy 187-721 (Channel Busy) 
SCH7 Set Dwell Time 187-721 (Set Dwell Time) 
SCH 6 Halt and Wait 187-721 (Halt and Wait) 
SCH; Contact Later 187-721 (Contact Later) 
SCHy4 Meet Me 187-721 (Meet Me) 
SCH)3 Poll Operator (default NAK) 187-721 (Poll Operator(default NAK)) 
SCH). Request Operator ACK 187-721 (Request Operator ACK) 
SCH); Schedule Periodic Function 187-721 (Schedule Periodic Function) 
SCH jo Quiet Contact 187-721 (Quiet Contact) 
SCH, Respond and Wait 187-721 (Respond and Wait) 
SCHs Set Sounding Interval 187-721 (Set Sounding Interval) 


SCH, Tune and wait 187-721 (Tune and Wait) 
SCH, Set Slot Width 187-721 (Set Slot Width) 
SCH; Year and Date 187-721 (Year and Date) 
SCH, Zulu Time 187-721 (Zulu Time) 

SCH; Do Not Respond 188-141 (Do Not Respond) 
SCH) Reserved (always set to 0) 

SCH, (LSB) Reserved (always set to 0) 
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A.5.6.7 Do not respond CMD. 

When an ALE controller receives this CMD in a transmission, it shall not respond unless a 
response is specifically required by some other CMD in the transmission (e.g., an LQA request or 
a DTM or DBM with ARQ requested). In a Do Not Responds CMD, no three-way ALE 
handshake needs to be completed. 


A.5.6.8 Position report (optional). 
See MIL-STD-187-721. 


A.5.6.9 User unique functions (UUFs). 

UUFs are for special uses, as coordinated with specific users or manufacturers, which use the 
ALE system in conjunction with unique, nonstandard, or non-ALE, purposes. There are 16384 
specific types of CMD UUF codes available, as indicated by a 14-bit (or two-character) unique 
index (UI). Each unique type of special function that employees a UUF shall have a specific UI 
assigned to it to ensure interoperability, compatibility, and identification. The UI shall be 
assigned for use before any transmission of the UUF or the associated unique activity, and the 
ALE UUF shall always include the appropriate UI when sent. 


The UUF shall be used only among stations that are specifically addressed and included within 
the protocol, and shall be used only with stations specifically capable of participating in the UUF 
activity, and all other (non-participating) stations should be terminated. There are two exceptions 
for stations that are not capable of participating in the UUF and are required to be retained in the 
protocol until concluded. They shall be handled using either of the two following procedures. 
First, the calling station shall direct all the addressed and included stations to stay linked for the 
duration of the UUF, to read and use anything that they are capable of during that time, and to 
resume acquisition and tracking of the ALE frame and protocol after the UUF ends. To 
accomplish this, and immediately before the CMD UUF, the sending station shall send the CMD 
STAY, which shall indicate the time period (T) for which the receiving stations shall wait for 
resumption of the frame and protocol. Second, the sending station shall use any standard CMD 
function to direct the non-participating stations to wait or return later, or do anything else 
appropriate and controllable through the standard orderwire functions. 


Ifa CMD UUF is included within an ALE frame, it shall only be within the message section. 
The UUF activity itself should be conducted completely outside of the frame and should not 
interfere with the protocols. If the UUF activity itself must be conducted within the message 
section, will occupy time on the channel, and is incompatible with the ALE system, that activity 
shall be conducted immediately after the CMD UUF and it shall be for a limited amount of time 
(T). A CMD STAY shall precede the UUF instruction, as described herein, to indicate that time 
(T). The sending station shall resume the same previous redundant word phase when the frame 
and protocol resumes, to ensure synchronization. The STAY function preserves maintenance of 
the frame and link. It instructs the stations to wait, because the amount of time occupied by the 
UUF activity or its signaling may conflict with functions such as the wait-for-activity timer (Twa). 
This may interfere with the protocols or maintenance of the link. In any case, the users of the 
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UUF shall be responsible for noninterference with other stations and users, and also for 
controlling their own stations and link management functions to avoid these conflicts. 


The UUF shall be constructed as follows and as shown in table A-XXX. The UUF word shall 
use the CMD (110) preamble in bits P3 through P1 (W1 through W3). The character in the first 
position shall be the pipe “)” or vertical bar “|” (1111100) in bits C1-7 through C1-1 (W4 through 
W10), which shall identify the “unique” function. The user or manufacturer-specific UI shall be 
a 14-bit (or two-character, 7-bit ASCII) code using bits UI-14 through UI-1 (W11 through W24). 
All unassigned UI codes shall be reserved and shall not be used until assigned for a specific use. 


TABLE A-XXX. User unique functions structure. 
User Unique 
Function Bits Word Bits 


CMD Preamble P3=1 
P2=1 
P1=0 


First Character | Cl (bit-7) =1 
Cl (bit-6)=1 
C1 (bit-5) =1 
C1 (bit-4) =1 
C1 (bit-3) =1 
Cl (bit-2) =0 
Cl (bit-1) =0 


First UI Character JI-1-7 
I-1-6 
JI-1-5 
1-1-4 
JI-1-3 
I-1-2 
JI-1-1 


Second UI Character ]-2-7 
JI-2-6 
]-2-5 
JI-2-4 
]-2-3 
JI-2-2 
I-2-1 


CMD user unique functions first character is “;” (1111100) for “unique.” 
Unique index (UI) characters UI-1 and UI-2 from central registry and 
assignment. 
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A.5.7 ALE message protocols. 


A.5.7.1 Overview. 

Three message protocols are available for carrying user data using the ALE waveform and signal 
structure. The characteristics of these three protocols are summarized in the table A-XXXI. All 
ALE controllers complying with this appendix shall implement the AMD protocol. 


TABLE A-XXXI. ALE message protocols. 


Protocol Mandatory | Character Peak 
Set Throughput 


AMD Expanded 64 55 b/s 
DTM unrestricted 61 b/s Bi 
DBM unrestricted 187 b/s Opt 


A.5.7.2. AMD mode (mandatory). 
The operators and controllers shall be able to send and receive simple ASCII text messages using 
only the existing station equipment. 


A.5.7.2.1_ Expanded 64-channel subset. 

The expanded 64 ASCII subset shall include all capital alphabetics (A-Z), all digits (0-9), the 
utility symbols “@” and “?,” plus 26 other commonly used symbols. See figure A-46. The 
expanded 64 subset shall be used for all basic orderwire message functions, plus special 
functions as may be standardized. For orderwire message use, the subset members shall be 
enclosed within a sequence of DATA (and REP) words and shall be preceded by an associated 
CMD (such as DTM). The CMD designates the usage of the information that follows, and shall 
also be preceded by a valid and appropriate calling cycle using the Basic 38 ASCII subset 
addressing. Digital discrimination of the expanded 64 ASCII subset may be accomplished by 
examination of the two MSBs (b7 and be), as all of the members within the “01” and “10” MSBs 
are acceptable. No parity bits are transmitted because the integrity of the information is protected 
by the basic ALE FEC and redundancy and may be ensured by optional use of the CMD CRC as 
described in A.5.6.1. The station shall have the capability to both send and receive AMD 
messages from and to both the operator and the controller. The station shall also have the 
capability to display any received AMD messages directly to the operator and controller upon 
arrival, and to alert them. The operator and controller shall have the capability to disable the 
display and the alarm when their functions would be operationally inappropriate. 
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FIGURE A-46. Expanded 64 ASCII subset (shown unshaded). 


A.5.7.2.2, AMD protocol. 

When an ASCII short orderwire AMD type function is required, the following CMD AMD 
protocol shall be used, unless another protocol in this standard is substituted. An AMD message 
shall be constructed in the standard word format, as described herein, and the AMD message 
shall be inserted in the message section of the frame. The receiving station shall be capable of 
receiving an AMD message contained in any ALE frame, including calls, responses, and 
acknowledgments. Within the AMD structure, the first word shall be a CMD AMD word, which 
shall contain the first three characters of the message. It shall be followed by a sequence of 
alternating DATA and REP words that shall contain the remainder of the message. The CMD, 
DATA, and REP words shall all contain only characters from the expanded ASCII 64 subset, 
which shall identify them as an AMD transmission. Each separate AMD message shall be kept 
intact and shall only be sent in a single frame, and in the exact sequence of the message itself. If 
one or two additional characters are required to fill the triplet in the last word sent, the position(s) 
shall be “stuffed” with the “space” character (0100000) automatically by the controller, without 
operator action. The end of the AMD message shall be indicated by the start of the frame 
conclusion, or by the receipt of another CMD. Multiple AMD messages may be sent within a 
frame, but they each shall start with their own CMD AMD with the first three characters. 
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A.5.7.2.3, Maximum AMD message size. 

Receipt of the CMD AMD word shall warn the receiving station that an AMD message is 
arriving and shall instruct it to alert the operator and controller and display the message, unless 
they disable these outputs. The station shall have the capability to distinguish among, and 
separately display, multiple separate AMD messages that were in one or several transmissions. 
The AMD word format shall consist of a CMD (110) in bits P3 through P1 (W1 through W3), 
followed by the three standard character fields C1, C2, and C3. In each character field, each 
character shall have its most significant bits (MSBs) bit 7 and bit 6 (C1-7 and C1-6, C2-7 and 
C2-6, and C3-7 and C3-6) set to the values of “01” or “10” (that is, all three characters are 
members of the expanded ASCII 64 subset). The rest of the AMD message shall be constructed 
identically, except for the alternating use of the DATA and REP preambles. 


Any quantity of AMD words may be sent within the message section of the frame within the 

Tm max limitation of 30 words (90 characters). Tim max shall be expanded from 30 words, to a 
maximum of 59 words, with the inclusion of CMD words within the message section. The 
maximum AMD message shall remain 30 words, exclusive of additional CMD words included 
within the message section of the frame. The maximum number of CMD words within the 
message section shall be 30. The message characters within the AMD structure shall be 
displayed verbatim as received. If a detectable information loss or error occurs, the station shall 
warn of this by the substitution of a unique and distinct error indication, such as all display 
elements activated (like a “block”’). The display shall have a capacity of at least 20 characters 
(DO: at least 40). The AMD message storage capacity, for recall of the most recently received 
message(s), shall be at least 90 characters plus sending station address. (DO: at least 400). By 
operator or controller direction, the display shall be capable of reviewing all messages in the 
AMD memory and shall also be capable of identifying the originating station’s address. If words 
are received that have the proper AMD format but are within a portion of the message section 
under the control of another message protocol (such as DTM), the other protocol shall take 
precedence and the words shall be ignored by the station’s AMD function. 


NOTE: If higher data integrity or reliability is required, the CMD DTM and DBM protocols 
should be used. 


A.5.7.3 DTM mode. 

The DTM ALE (orderwire) message protocol function enables stations to communicate (full 
ASCII or unformatted binary bits) messages to and from any selected station(s) for direct output 
to and input from associated data terminals or other date terminal equipment (DTE) devices 
through their standard data circuit-terminating equipment (DCE) ports. The DTM data transfer 
function is a standard speed mode (like AMD) with improved robustness, especially against 
weak signals and short noise bursts. When used over medium frequency (MF)/HF by the ALE 
system, DTM orderwire messages may be unilateral or bilateral, and broadcast or acknowledged. 
As the DTM data blocks are of moderate sizes, this special orderwire message function enables 
utilization of the inherent redundancy and FEC techniques to detect weak HF signals and tolerate 
short noise bursts. 
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The DTM data blocks shall be fully buffered at each station and should appear transparent to the 
using DTEs or data terminals. As a DO, and under the direction of the operator or controller, the 
stations should have the capability of using the DTM data traffic mode (ASCII or binary bits) to 
control switching of the DTM data traffic to the appropriate DCE port or associated DTE 
equipment, such as to printers and terminals (if ASCII mode), or computers and cryptographic 
devices (if binary bits mode). As an operator or controller selected option, the received DTM 
message may also be presented on the operator display similar to the method for AMD in 
Pade 


There are four CMD DTM modes: BASIC, EXTENDED, NULL, and ARQ. The DTM BASIC 
block ranges over a moderate size and contains a variable quantity of data, from zero to full as 
required, which is exactly measured to ensure integrity of the data during transfer. The DTM 
EXTENDED blocks are variable over a larger range of sizes, in integral multiples of the ALE 
basic word, and are filled with integral multiples of message data. The DTM NULL and ARQ 
modes are used for both link management, and error and flow control. The characteristics of the 
CMD DTM orderwire message functions are listed in table A-X XXII and are summarized below: 


CMD DTM Mode BASIC EXTENDED ARQ NULL 
Maximum Size, Bits 651 7371 0 
Cyclic Redundancy Check 16 Bits 16 Bits 0 
Data Capacity, ASCII 0-93 3-1053, by 3 0 
Data Capacity, Bits 1-651 21-7371, by 21 0 
ALE Word Redundancy 3 Fixed 3 Fixed 0 
Data Transmission 392 ms - 392 ms - 0 
12.152 sec 2.29 min 
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TABLE A-XXXII. DTM characteristics. 
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When an ASCII, or binary bit, digital data message function is required, the following CMD 
DTM orderwire structures and protocols shall be used as specified herein, unless another 
standardized protocol is substituted. The DTM structure shall be inserted within the message 
section of the standard ALE frame. A CMD DTM word shall be constructed in the standard 
24-bit format, using the CMD preamble (see table A-X XXIII). The message data to be 
transferred shall also be inserted in words, using the DATA and REP preambles. The words shall 
then be Golay FEC encoded and interleaved, and then shall be transmitted immediately following 
the CMD DTM word. A CMD CRC shall immediately follow the data block words, and it shall 
carry the error control CRC FCS. 


When the DTM structure transmission time exceeds the maximum limit for the message section 
(Tm max), the DTM protocol shall take precedence and shall extend the T,, limit to accommodate 
the DTM. The DTM mode preserves the required consistency of redundant word phase during 
the transmission. The message expansion due to the DTM is always a multiple of one T;,, as the 
basic ALE word structure is used. The transmission time of the DTM data block (DTM words x 
392 ms) does not include the T,, for the preceding CMD DTM word or the following CMD 
CRC. Figure A-47 shows an example of a DTM message structure. 


ORIGINAL MESSAGE: 
THE QUICK BROWN FOX! 


: ALE DATA TEXT TRANSMISSION: ©VOxr® 


To | cmp | DATA DATA | cMD 
B/ ™ |T HE; s§ Q x, NI cx 
I tod tod tod tod I I L I 


O®@ siiii I 
ORC) 


CALLING MESSAGE MESSAGE DATA FIELD FRAME CONCLUSION 
CYCLE DESCRIPTION CHECK TERMINATOR 
AND SEQUENCE AND 
DESTINATION ORIGIN 


WAAITBBEFERR 


5-CHANNEL EXAMPLE SHOWN, SCANNED IN 
1 SECOND WITH ONE-WORD ADDRESSES. 


@ _TUNINGREQUIRED INTIALLY (T}) 
© WATUISTEN) TIME (Ty). 


@) CALLING CYCLE (7...) DEPENDS ON SCAN PERIOD (Ts). NOTES: 


© Vormiow InseRTION OF CMD AND INFORMATION F LOA) 1. CMDDTM IS USED TO INDICATE THE NUMBER OF WORDS IN 
EACH WORD ADDS, THE MESSAGE, WHETHER ASCII OR BINARY DATA, AND THE NUMBER 
OF STUFF BITS IN THE LAST WORD. 


© TWAS TERMINATES PROTOCOL, SUPPRESSES ALERTS. 


TIS NORMALLY COMPELLED BY CALL RECEIPT ( A PAUSES FOR AN 2. CMDCRC CONTAINS FOUR HEXADECIMAL CHARACTERS 
@ APPROPRIATE RESPONSE FROM B). CONSTITUTING THE 16-BIT FRAME CHECK SEQUENCE. 


FIGURE A-47. DTM structure example. 
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The DTM protocol shall be as described herein. The CMD DTM BASIC and EXTENDED 
formats (herein referred to as DTM data blocks) shall be used to transfer messages and 
information among stations. The CMD DTM ARQ format shall be used to acknowledge other 
CMD DTM formats and for error and flow control, except for non-ARQ and one-way broadcasts. 
The CMD DTM NULL format shall be used to (a) interrupt (“break”) the DTM and message 
flow, (b) to interrogate station to confirm DTM capability before initiation of the DTM message 
transfer protocols, and (c) to terminate the DTM protocols while remaining linked. When used 
in ALE handshakes and subsequent exchanges, the protocol frame terminations for all involved 
stations shall be TIS until all the DTM messages are successfully transferred, and all are 
acknowledged if ARQ error control is required. The only exceptions shall be when the protocol 
is a one-way broadcast or the station is forced to abandon the exchange by the operator or 
controller, in which cases the termination should be TWAS. 


Once a CMD DTM word of any type has been received by a called (addressed) or linked station, 
the station shall remain on channel for the entire specified DTM data block time (if any), unless 
forced to abandon the protocol by the operator or controller. The start of the DTM data block 
itself shall be exactly indicated by the end of the CMD DTM BASIC or EXTENDED word itself. 
The station shall attempt to read the entire DTM data block information in the DATA and REP 
words, and the following CMD CRC, plus the expected frame continuation, which shall contain a 
conclusion (possibly preceded by additional functions in the message section, as indicated by 
additional CMD words). 


With or without ARQ, identification of each DTM data block and its associated orderwire 
message (if segmented into sequential DTM data blocks) shall be achieved by use of the 
sequence and message control bits, KD1 and KD2, (as shown in table A-X XXIII), which shall 
alternate with each DTM transmission and message, respectively. The type of data contained 
within the data block (ASCII or binary bits) shall be indicated by KD3 as a data identification bit. 
Activation of the ARQ error control protocol shall use the ARQ control bit KD4. Ifno ARQ is 
required, such as in one-way broadcasts, multiple DTM data blocks may be sent in the same 
frame, but they shall be in proper sequential order if they are transferring a segmented message. 


When ARQ error or flow control is required, the CMD DTM ARQ shall identify the 
acknowledged DTM data block by the use of the sequence and message control bits KD1 and 
KD2, which shall be set to the same values as the immediately preceding and referenced DTM 
data block transmission. Control bit KD3 shall be used as the DTM flow control to pause or 
continue (or resume) the flow of the DTM data blocks. The ACK and request-for-repeat (NAK) 
functions shall use the ARQ control bit KD4. If no ARQ has been required by the sending 
station, but the receiving station needs to control the flow of the DTM data blocks, it shall use 
the DTM ARQ to request a pause in, and resumption of, the flow. 
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TABLE A-XXXIII. DTM structure. 


| ss DTM Bits Word Bits 
M MSB wi 


CMD 
preamble 


First 
character 
6 wel 2. 


SB 


LSB 
Cl (bit-7) = 1 
Cl (bit-6) = 1 
Cl (bit-5) = 0 
Cl (bit-4) =0 
Cl (bit-3) = 1 
Cl (bit-2) =0 
Cl (bit-1) =0 


Control 
bits 


10. 


CMD DTM and DTM ARQ first character is “d” for “data”. 

With DTM transmission, control bit KD4 (W11) is set to “0” for no ACK request, and “1” for 
ACK request. 

Ifa DTM ARQ transmission, control bit KD4 (W11) is set to “0” for binary bits, and “1” for 7-bit 
ASCII characters. 

With DTM transmission, control bit KD3 (W12) is set to “0” for binary bits and “1” for 7-bit 
ASCII characters. 

Ifa DTM ARQ transmission, control bit KD3 (W12) is set to “0” for flow continue, and “1” for 
flow pause. 

With DTM transmissions, control bit KD2 (W13) is set (a) the same (“0” or “1”’) as the 
sequentially adjacent DTM(s) if the transmitted data field is to be reintegrated as part of a larger 
DTM, and (b) alternately different if independent from the prior adjacent DTM data field(s). 

Ifa DTM ARQ transmission, control bit KD2 (W13) is set the same as the referenced DTM 
transmission. 

With DTM transmission, control bit KD1 (W14) is set alternately to “0” and “1” in any sequence 
of DTMs, as a sequence control. 

Ifa DTM ARQ transmission, control bit KD1 (W14) is set the same as the referenced DTM 
transmission. 

Data Code (DC) bits are from table A-XXXII. 
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When data transfer ARQ error and flow control is required, the DTM data blocks shall be sent 
individually, in sequence, and each DTM data block shall be acknowledged before the next DTM 
data block is sent. Therefore, with ARQ there shall be only one DTM data block transmission in 
each ALE frame. If the transmitted DTM data block causes a NAK in the returned DTM ARQ, 
as described below, or if ACK or DTM ARQ is detected in the returned frame, or if no ALE 
frame is detected at all, the sending station shall resend an exact duplicate of the 
unacknowledged DTM data block. It shall send and continue to resend duplicates (which should 
be up to at least seven) one at a time and with appropriate pauses for responses, until the 
involved DTM data block is specifically acknowledged by a correct DTM ARQ. Only then shall 
the next DTM data block in the sequence be sent. If the sending station is frequently or totally 
unable to detect ALE frame or DTM ARQ responses, it should abort the DTM transfer protocol, 
terminate the link, and relink and reinitiate the DTM protocol on a better channel, under operator 
or controller direction. 


Before initiation of the DTM data transfer protocols, the sending stations should confirm the 
existence of the DTM capability in the intended receiving stations, if not already known. When a 
DTM interrogation function is required, the following protocol shall be used. Within any 
standard protocol frame (using TIS), the sending station shall transmit a CMD DTM NULL, with 
ARQ required, to the intended station(s). These receiving stations shall respond with the 
appropriate standard frame and protocol, with the following variations. They shall include a 
CMD DTM ARQ if they are DTM capable, and they shall omit it if they are not DTM capable. 
The sending station shall examine the ALE and DTM ARQ responses for existence, correctness, 
and the status of the DTM KD control bits, as described herein. The transmitted CMD DTM 
NULL shall have its control bits set as follows: KD1 and KD2 set opposite of any subsequent 
and sequential CMD DTM BASIC or EXTENDED data blocks, which will be transmitted next; 
KD3 set to indicate the intended type of traffic, and KD4 set to require ARQ. The returned CMD 
DTM ARQ shall have its control bits set as follows: KD1 and KD2 set to match the 
interrogating DTM NULL; KD3 set to indicate if the station is ready for DTM data exchanges, or 
if a pause is requested; and KD4 set to ACK if the station is ready to accept DTM data 
transmissions with the specified traffic type, and NAK if it cannot or will not participate, or it 
failed to read the DTM NULL. 


The sending (interrogating) station shall handle any and all stations that return a NAK, or do not 
return a DTM ARQ at all, or do not respond at all, in any combination of the following three 
ways, and for any combination of these stations. The specific actions and stations shall be 
selected by the operator or controller. The sending station shall: (a) terminate the link with 
them, using an appropriate and specific call and the TWAS terminator; or (b) direct them to 
remain and stay linked during the transmissions, using the CMD STAY protocol in each frame 
immediately before each CMD DTM word and data block sent; or (c) redirect them to do 
anything else that is controllable using the CMD functions described within this standard. 


Each received DTM data block shall be examined using the CRC data integrity test included 
within the mandatory associated CMD CRC that immediately follows the DTM data block 
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structure. If the data block passes the CRC test, the data shall be passed through to the 
appropriate DCE port (or normal output as directed by the operator or controller). If the data 
block is part of a larger message segmented before DTM transfer, it shall be recombined before 
output. If any DTM data blocks are received and do not pass the CRC data integrity test, any 
detectable but uncorrectable errors or areas likely to contain errors and should be tagged for 
further analysis, error control, or inspection by the operator or controller. 


If ARQ is required, the received but unacceptable data block shall be temporarily stored, and a 
DTM ARQ NAK shall be returned to sender, who shall retransmit an exact duplicate DTM data 
block. Upon receipt of the duplicate, the receiving station shall again test the CRC. If the CRC 
is successful, the data block shall be passed through as described before, the previously 
unacceptable data block should be deleted, and a DTM ARQ ACK shall be returned. If the CRC 
fails again, both the duplicate and the previously stored data blocks shall be used to correct, as 
possible, errors and to create an “improved” data block. See figure A-48 for an example of data 
block reconstruction. The “improved” data block shall then be CRC tested. If the CRC is 
successful, the “improved” data block is passed through, the previously unacceptable data blocks 
should be deleted, and a DTM ARQ ACK shall be returned. If the CRC test fails, the 
“improved” data block shall be stored and a DTM ARQ NAK shall be returned. This process 
shall be repeated until: (a) a received duplicate, or an “improved” data block passes the CRC test 
(the data block is passed through, and a DTM ARQ ACK is returned); (b) the maximum number 
of duplicates (such as seven or more) have been sent without success (with actions by the sender 
as described above); or (c) the operators or controllers terminate or redirect the DTM protocol. 
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* ORIGINAL MESSAGE: 
THE QUICK BROWN FOX! 
EACH ALE DATA TEXT TRANSMISSION: 


TO CMD DATA REP DATA REP DATA REP 
B om™ TH EIS qoufitc xié B RJ} oO Ww]é F 


FIRST TRY - BROKEN MESSAGE (SEND NAK): 
cop cmp 
a ee a a § § s (CRC 9602 
B BB B REJECT) 
SECOND TRY - BROKEN MESSAGE (SEND NAK): 
CMD 
OTM é s 5 § s§ § s (CRC 51E4 
7 AT THE ®B UK » a u REJECT) 


THIRD TRY - BROKEN MESSAGE (SEND ACK, SEE COMBINED OVERLAYS) 


CMD 


eM s s (CRC A712 


Ss Ss 
u U iU U 
a es ae ae ausick § [ REJECT) 


+ COMBINED OVERLAYS ON WORD BASIS, THREE TRIES 


orn 6 : P (CRC 2C5B 
7 A 7 TH EP QuUitI Cc K P ! GOOD) 


* FINALLY RECEIVED MESSAGE 
THE QUICK BROWN FOX! NOTES: 


1. CMD DTM IN THIS EXAMPLE INDICATES SEVEN WORDS WITH 
ASCII CHARACTERS AND SEVEN STUFF BITS IN THE LAST WORD. 


S 
2. g INDICATES SUBSTITUTE CHARACTERS WHEN BAD AND REJECTED. 


3. . INDICATES SPACE FUNCTION. 


4. CMD CRC CONTAINS FOUR HEXADECIMAL CHARACTERS CONSTITUTING 
THE 16-BIT FRAME CHECK SEQUENCE. 


FIGURE A-48. Data test message reconstruction (overlay). 


During reception of ALE frames and DTM data blocks, it is expected that fades, interferences, 
and collisions will occur. The receiving station shall have the capability to maintain 
synchronization with the frame and the DTM data block transmission, once initiated. It shall also 
have the capability to read and process any colliding and significantly stronger (that is, readable) 
ALE signals without confusing them with the DTM signal (basic ALE reception in parallel, and 
always listening). Therefore, useful information that may be derived from readable collisions of 
ALE signals should not be arbitrarily rejected or wasted. The DTM structures, especially the 
DTM EXTENDED, can tolerate weak signals, short fades, and short noise bursts. For these 
cases and for collisions, the DTM protocol can detect DTM words that have been damaged and 
“tag” them for error correction or repeats. The DTM constructions are described herein. Within 
the DTM data block structure, the CMD DTM word shall be placed ahead of the DTM data block 
itself. The DTM word shall alert the receiving station that a DTM data block is arriving, how 
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long it is, what type of traffic it contains, what its message and block sequence is, and if ARQ is 
required. It shall also indicate the exact start of the data block (the end of the CMD DTM word), 
and shall initiate the reception, tracking, decoding, reading, and checking of the message data 
contained within the data block, which itself is within the DATA and REP words. The message 
data itself shall be either one of two types, binary bits or ASCII. 


The ASCII characters (typically used for text) shall be the standard 7-bit length, and the start, 
stop, and parity bits shall be removed at the sending (and restored at the receiving) station. The 
binary bits (typically used for other character formats, computer files, and cryptographic devices) 
may have any (or no) pattern or format, and they shall be transferred transparently (that is, 
exactly as they were input to the sending station) with the same length and without modification. 


The size of the DTM BASIC or EXTENDED data block shall be the smallest multiple of DATA 
and REP words that will accommodate the quantity of the ASCII or binary bits message data to 
be transferred in the DTM data block. If the message data to be transferred does not exactly fit 
the unencoded data field of the DTM block size selected, the available empty positions shall be 
“stuffed” with ASCII “DEL” (1111111) characters or all “1” bits. The combined message and 
“stuff” data in the uncoded DTM data field shall then be checked by the CRC for error control in 
the DTM protocol. The resulting 16-bit CRC word shall always be inserted into the CMD CRC 
word that immediately follows the DTM data block words themselves. All the bits in the data 
field shall then be inserted into standard DATA and REP words on a 21-bit or three-character 
basis and Golay FEC encoded, interleaved, and tripled for redundancy. Immediately after the 
CMD DTM word, the DTM DATA and REP words shall follow standard word format, and the 
CMD CRC shall be at the end. 


The DTM BASIC data block has a relatively compact range of sizes from 0 to 31 words and shall 
be used to transfer any quantity of message data between zero and the maximum limits for the 
DTM BASIC structure, which is up to 651 bits or 93 ASCII characters. It is capable of counting 
the exact quantity of message data it contains, on a bit-by-bit basis. It should be used as a single 
DTM for any message data within this range. It shall also be used to transfer any message data in 
this size range that is an “overflow” from the larger size (and increments) DTM EXTENDED 
data blocks, which shall immediately precede the DTM BASIC in the DTM sequence of sending. 


The DTM EXTENDED data blocks are also variable in size in increments of single ALE words 
up to 351. They should be used as a single, large DTM to maximize the advantages of DTM 
throughput. The size of the data block should be selected to provide the largest data field size 
that can be totally filled by the message data to be transferred. Any “overflow” shall be in a 
message data segment sent within an immediately following and appropriately sized DTM 
EXTENDED or BASIC data block. Under operator or controller direction, multiple DTM 
EXTENDED data blocks, with smaller than the maximum appropriate ID sizes, should be 
selected if they will optimize DTM data transfer throughput and reliability. However, these 
multiple data blocks will require that the message data be divided into multiple segments at the 
sending station, that they be sent only in the exact order of the segments in the message, and that 
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the receiving stations recombine the segments into a complete received message. When binary 
bits are being transferred, the EXTENDED data field shall be filled exactly to the last bit. When 
ASCII characters are being transferred, there are no stuff bits as the 7-bit characters fit the ALE 
word 21-bit data field exactly. 


If stations are exchanging DTM data blocks and DTM ARQs, they may combine both functions 
in the same frames, and they shall discriminate based on the direction of transmission and the 
sending and destination addressing. If ARQ is required in a given direction, only one DTM data 
block shall be allowed within any frame in that direction, and only one DTM ARQ shall be 
allowed in each frame in the return direction. If no ARQ is required in a given direction, 
multiple DTM data blocks may be included in frames in that direction, and multiple DTM ARQ’s 
may be included in the return direction. 


As always throughout the DTM protocol, any sequence of DTM data blocks to be transferred 
shall have the KD1 sequence control bits alternating with the preceding and following DTM data 
blocks (except duplicates for ARQ, which shall be exactly the same as the originally transmitted 
DTM data block). 


Also, all multiple DTM data blocks transferring multiple segments of a larger data message shall 
all have their KD2 message control bits set to the same value, and opposite of the preceding and 
following messages. If a sequence of multiple but unrelated DTM data blocks are sent (such as 
several independent and short messages within several DTM BASIC data blocks), they may be 
sent in any sequence. However, the KD1 or KD2 sequence and message control bits shall 
alternate with those in the adjacent DTM data blocks. 


The CMD DTM words shall be constructed as shown in table A-X XXIII. The preamble shall be 
CMD (110) in bits P3 through P1 (W1 through W3). The first character shall be “d” (1100100) 
in bits C1-7 through C1-1) (W4 through W10), which shall identify the DTM “data” function. 


For DTM BASIC, EXTENDED, and NULL, when the “ARQ” control bit KD4 (W11) is set to 
“0,” no correct data receipt acknowledgment is required; and when set to “1,” it is required. For 
DTM ARQ, “ARQ” control bit KD4 is set to “0” to indicate acknowledgment or correct data 
block receipt (ACK); and when set to “1,” it indicates a failure to receive the data and is therefore 
a request-for-repeat (NAK). For DTM ARQ responding to a DTM NULL interrogation, KD4 
“Q” indicates non-participation in the DTM protocol or traffic type, and KD4 “1” indicates 
affirmative participation in both the DTM protocol and traffic type. 


For DTM BASIC, EXTENDED, and NULL, when the “data type” control bit KD3 (W12) is set 
to “0,” the message data contained within the DTM data block shall be binary bits with no 
required format or pattern; and when KD3 is set to “1” the message data is 7-bit ASCII 
characters. For DTM ARQ, “flow” control bit KD3 is set to indicate that the DTM transfer flow 
should continue, or resume; and when KD3 is set to “1” it indicates that the sending station 
should pause (until another and identical DTM ARQ is returned, except that KD3 shall be “0”’). 
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For DTM BASIC, EXTENDED, and NULL, when the “message” control bit KD2 (W13) is set 
to the same value as the KD2 in any sequentially adjacent DTM data block, the message data 
contained within those adjacent blocks (after individual error control) shall be recombined with 
the message data within the present DTM data block segment-by-segment to reconstitute the 
original whole message, and when KD? is set opposite to any sequentially adjacent DTM data 
blocks, those data blocks contain separate message data and shall not be combined. For DTM 
ARQ, “message” control bit KD2 shall be set to match the referenced DTM data block KD2 
value to provide message confirmation. 


For DTM BASIC, EXTENDED, and NULL, the “sequence” control bit KD1 (W14) shall be set 
opposite to the KD1 value in the sequentially adjacent DTM BASIC, EXTENDED, or NULLs to 
be sent (the KD1 values therefore alternate, regardless of their message dependencies). When 
KD1 is set to the same value as any sequentially adjacent DTM sent, it indicates that it is a 
duplicate (which shall be exactly the same). For DTM ARQ, “sequence” control bit KD1 shall 
be set to match the referenced DTM data block or NULL KD1 value to provide sequence 
confirmation. 


When used for the DTM protocols, the ten DTM data code (DC) bits DC10 through DC1 (W15 
through W24) shall indicate the DTM mode (BASIC, EXTENDED, ARQ, or NULL). They shall 
also indicate the size of the message data and the length of the data block. The DTM NULL DC 
value shall be “0” (0000000000), and it shall designate the single CMD DTM NULL word. The 
DTM EXTENDED DC values shall range from “1” (0000000001) to “351” (0101011111), and 
they designate the CMD DTM EXTENDED word and the data block multiple of DATA and REP 
words that define the variable data block sizes. The EXTENDED sizes shall range from | to 351 
words, with a range of 21 to 7371 binary bits, in increments of 21; or three to 1053 ASCII 
characters, in increments of three. The DTM BASIC DC values shall range from “353” 
(0101100001) to “1023” (1111111111), and they shall designate the CMD DTM BASIC word and 
the exact size of the message data in compact and variable size data blocks, with up to 651 binary 
bits or 93 ASCII characters. The DTM ARQ DC value shall be “352” (0101100000), and it shall 
designate the single CMD DTM ARQ word. The DC values “384” (0110000000) and all higher 
multiples of “32m” (m x 100000) shall be reserved until standardized. See table A-XXXII for 
DC values and DTM block sizes and other characteristics. 


A.5.7.4 DBM mode. 

The DBM ALE (orderwire) message protocol function enables ALE stations to communicate 
either full ASCII, or unformatted binary bit messages to and from any selected ALE station(s) for 
direct output to and input from associated data terminal or other DTE devices through their 
standard DCE ports. This DBM data transfer function is a high-speed mode (relative to DTM 
and AMD) with improved robustness, especially against long fades and noise bursts. When used 
over MF/HF by the ALE system, DBM orderwire messages may be unilateral or bilateral, and 
broadcast or acknowledged. As the DBM data blocks can be very large, this special orderwire 
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message function enables exploitation of deep interleaving and FEC techniques to penetrate HF- 
channel long fades and large noise bursts. 


The DBM data blocks shall be fully buffered at each station and should appear transparent to the 
using DTEs or data terminals. As a design objective and under the direction of the operator or 
controller, the stations should have the capability of using the DBM data traffic mode (ASCII or 
binary bits) to control switching of the DBM data traffic to the appropriate DCE port or 
associated DTE equipment, such as to printers and terminals (if ASCII mode) or computers and 
cryptographic devices (if binary bits mode). As an operator or controller-selected option, the 
received DBM message may also be presented on the operator display, similar to the method for 
AMD in table A.5.7.2. 


There are four CMD DBM modes: BASIC, EXTENDED, NULL, and ARQ. The DBM BASIC 
block is a fixed size and contains a variable quantity of data, from zero to full as required, which 
is exactly measured to ensure integrity of the data during transfer. The DBM EXTENDED 
blocks are variable in size in integral multiples of the BASIC block, and are filled with integral 
multiples of message data. The DBM NULL and ARQ modes are used for both link 
management, and error and flow control. The characteristics of the CMD DBM orderwire 
message functions are listed in table A-X XXIV, and they are summarized below: 


CMD DBM Mode BASIC EXTENDED ARQ NULL 
Maximum Size, Bits 588 262836 0 

CRC 16 Bits 16 Bits 0 

Data Capacity, ASCII 0-81 81-37377, by 84 0 

Data Capacity, Bits 0-572 572-261644, by 588 0 

ALE Word 49 Fixed 49-21805, by 49 0 
Redundancy 

Data Transmission 3.136 Sec 3.136 sec - 23.26 0 

min, 


by 3.136 sec increments 
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TABLE A-XXXIV. DBM characteristics. 


WORD BITS 
DBM CODE|_ INTER- BINARY ASCII BLOCK TOTAL 
Wl See ar W 24 (DC) LEAVE BITS CHAR TIME DBM 
DECIMAL | DEPTH DATA DATA (T.,) 
DBM CODE BITS | ““¢) iD} 
BC 10---------- BC 1 
DBM NULL* 
DBM 
EXTENDED 
(FULL) 
(RESERVED) 
DBM 
BASIC 
(EXACT) 
DBM ARQ* 
(RESERVED)* 
(RESERVED)* 1111111111 1023 --- ae a22 aos mee 
NOTE: 
*NO INTERNAL CRC USED. 


When an ASCII, or binary bit, digital data message function is required, the following CMD 
DBM orderwire structures and protocols shall be used as specified herein, unless another 
standardized protocol is substituted. The DBM structure shall be inserted within the message 
section of the standard frame. A CMD DBM word shall be constructed in the standard format. 
The data to be transferred shall be Golay FEC encoded, interleaved (for error spreading during 
decoding), and transmitted immediately following the CMD DBM word. 


When the DBM structure transmission time exceeds the maximum for the message section 

(Tm max), the DBM protocol shall take precedence and shall extend the T» limit to accommodate 
the DBM. The DBM mode preserves the required consistency of redundant word phase during 
the transmission. The message expansion due to the DBM is always a multiple of 8 T,y, as the 
interleaver depth is always a multiple of 49. The transmission time of the DBM data block 
(Tam) itself is equal to (interleaver depth x 64ms), not including the T,, for the preceding CMD 
DBM word. Figure A-49 shows an example of an exchange using the DBM orderwire to transfer 
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and acknowledge messages. Figure A-50 shows an example of a DBM data interleaver, and 


figure A-51 shows the transmitted DBM bit-stream sequence. 
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FIGURE A-49. Data test message structure and ARO example. 
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FIGURE A-50. DBM interleaver and deinterleaver. 
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FIRST BIT SENT 
FIRST TRIBIT (TONE) SENT 


START OF SECOND TONE 


NEXT TO LAST TONE eo \ LAST BIT SENT 


LAST TRIBITS (TONE) SENT. 


Notes: 
1. Quantity of tones sent = 2M/3 = (2 X 12 X ID)/3 = ID X 8. 
2. Time of block sent = ID x 8 x 8 ms = ID x 64 ms. 


FIGURE A-51. DBM example. 


The DBM protocol shall be as described herein. The CMD DBM BASIC and EXTENDED 
formats (herein referred to as DBM data blocks) shall be used to transfer messages in information 
among ALE stations. The CMD DBM ARQ format shall be used to acknowledge other CMD 
DBM formats and for error and flow control, except for non-ARQ and one-way broadcasts. The 
CMD DBM NULL format shall be used to: (a) interrupt (“break’’) the DBM and message flow; 
(b) to interrogate stations to confirm DBM capability before initiation of the DBM message 
transfer protocols; and (c) to terminate the DBM protocols while remaining linked. When used 
in handshakes and subsequent exchanges, the protocol frame terminations for all involved 
stations shall be TIS until all the DBM messages are successfully transferred, and all are 
acknowledged if ARQ error control is required. The only exceptions shall be when the protocol 
is a one-way broadcast or the station is forced to abandon the exchange by the operator or 
controller, in which cases the termination should be TWAS. 
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Once a CMD DBM word of any type has been received by a called (addressed) or linked station, 
the station shall remain on channel for the entire specified DBM data block time (if any), unless 
forced to abandon the protocol by the operator or controller. The start of the DBM data block 
itself shall be exactly indicated by the end of the CMD DBM BASIC or EXTENDED word itself. 
The station shall attempt to read the entire DBM data block information, plus the expected frame 
continuation, which shall contain a conclusion (possibly preceded by additional functions in the 
message section, as indicated by additional CMD words). 


With or without ARQ, identification of each DBM data block and its associated orderwire 
message (if segmented into sequential DBM data blocks) shall be achieved by use of the 
sequence and message control bits, KB1 and KB2, (see table A-XXXV) which shall alternate 
with each DBM transmission and message, respectively. The type of data contained within the 
data block (ASCII or binary bits) shall be indicated by KB3 as a data identification bit. 
Activation of the ARQ error-control protocol shall use the ARQ control bit KB4. If no ARQ is 
required, such as in one-way broadcasts, multiple DBM data blocks may be sent in the same 
frame, but they shall be in proper sequence if they are transferring a segmented message. 
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TABLE A-XXXV. DBM structures. 
PE BM Bits Word Bits 


CMD W3 
preamble 


First Cl (bit-7) = 1 
character Cl (bit-6) = 1 
“b” Cl (bit-5) =0 
Cl (bit-4) =0 
Cl (bit-3) =0 
Cl (bit-2) = 1 
Cl (bit-1) =0 


Control 
bits 


CMD DBM and DBM ARQ first character is “b” for “block.” 
With DBM transmission, control bit KB4 (W11) is set to “0” for no ACK request, and “1” for 
ACK request. 
Ifa DBM ARQ transmission, control bit KB4 (W11) is set to “0” for ACK, and “1” for NAK. 
With DBM transmissions, control bit KB3 (W12) is set to “0” for binary bits and “1” for 7-bit 
ASCH characters. 
Ifa DBM ARQ transmission, control bit KB3 (W12) is set to “0” for flow continue, and “1” for 
flow pause. 
With DBM transmissions, control bit KB2 (W13) is set: (a) the same (“0” or “1’’) as the 
sequentially adjacent DBM(s) if the transmitted data field is to be reintegrated as part of a larger 
DBM, and (b) alternately different if independent from the prior adjacent DBM data field(s). 
Ifa DBM ARQ transmission, control bit KB2 (W13) is set the same as the referenced DBM 
transmission. 
With DBM transmissions, control bit KB1 (W14) is set alternately to “0” and “1” in any sequence 
of DBMs as a sequence control. 
Ifa DBM ARQ transmission, control bit KB1 (W14) is set the same as the referenced DBM 
transmission. 

10. Block code (BC) bits are from table A-XXXIV. 
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When ARQ error or flow control is required, the CMD DBM ARQ shall identify the 
acknowledged DBM data block by the use of the sequence and message control bits KB1 and 
KB2, which shall be set to the same values as the immediately preceding and referenced DBM 
data block transmission. Control bit KB3 shall be used as the DBM flow control to pause or 
continue (or resume) the flow of the DBM data blocks. The ACK and NAK functions shall use 
the ARQ control bit KB4. Ifno ARQ has been required by the sending station, but the receiving 
station needs to control the flow of the DBM data blocks, it shall use the DBM ARQ to request a 
pause in, and resumption of, the flow. 


When data transfer ARQ error and flow control is required, the DBM data blocks shall be sent 
individually and in sequence. Each DBM data block shall be individually acknowledged before 
the next DBM data block is sent. Therefore, with ARQ there shall be only one DBM data block 
transmission in each frame. If the transmitted DBM data block causes a NAK in the returned 
DBM ARQ, as described below, or if no ACK or DBM ARQ is detected in the returned frame, or 
if no frame is detected at all, the sending station shall resend an exact duplicate of the 
unacknowledged DBM data block. It shall continue to resend duplicates (which should be at 
least seven), one at a time and with appropriate pauses for responses, until the involved DBM 
data block is specifically acknowledged by a correct DBM ARQ. Only then shall the next DBM 
data block in the sequence be sent. If the sending station is frequently or totally unable to detect 
frame or DBM ARQ responses, it should abort the DBM transfer protocol, terminate the link and 
relink and reinitiate the DBM protocol on a better channel (under operator or controller 
direction). 


Before initiation of the DBM data transfer protocols, the sending stations should confirm the 
existence of the DBM capability in the intended receiving stations, if not already known. When a 
DBM interrogation function is required, the following protocol shall be used. Within any 
standard protocol frame (using TIS), the sending station shall transmit a CMD DBM NULL, with 
ARQ required, to the intended station(s). These receiving stations shall respond with the 
appropriate standard frame and protocol, with the following variations. They shall include a 
CMD DBM ARQ if they are DBM capable, and they shall omit it if they are not DBM capable. 
The sending station shall examine the ALE and DBM ARQ responses for existence, correctness, 
and the status of the DBM KB control bits, as described herein. The transmitted CMD DBM 
NULL shall have its control bits set as follows: KB1 and KB2 set opposite of any subsequent 
and sequential CMD DBM BASIC or EXTENDED data blocks which will be transmitted next; 
KB3 set to indicate the intended type of traffic; and KB4 set to require ARQ. The returned CMD 
DBM ARQ shall have its control bits set as follows: KB1 and KB2 set to match the interrogating 
DBM NULL; KB3 set to indicate if the station is ready for DBM data exchanges, or if a pause is 
requested; and KB4 set to ACK if the station is ready to accept DBM data transmissions with the 
specified traffic type, and NAK if it cannot or will not participate, or if it failed to read the DBM 
NULL. 


The sending (interrogating) station shall handle any stations which return a NAK, or do not 
return a DBM ARQ, or do not respond, in any combination of the following, and for any 
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combination of these stations. The specific actions and stations shall be selected by the operator 
or controller. The sending station shall: (a) terminate the link with these stations, using an 
appropriate and specific call and the TWAS terminator; (b) direct the stations to remain and stay 
linked during the transmissions, using the CMD STAY protocol in each frame immediately 
before each CMD DBM word and data block sent; or (c) redirect them to do anything else which 
is controllable using the CMD functions described within this standard. 


Each received DBM data block shall be examined using the CRC data integrity test which is 
embedded within the DBM structure and protocol. If the data block passes the CRC test, the data 
shall be passed through to the appropriate DCE port (or normal output as directed by the operator 
or controller). If the data block is part of a larger message which was segmented before DBM 
transfer, it shall be recombined before output. If any DBM data blocks are received and do not 
pass the CRC data integrity test, any detectable but uncorrectable errors; or areas likely to contain 
errors, should be tagged for further analysis, error control, or inspection by the operator or 
controller. 


If ARQ is required, the received but unacceptable data block shall be temporarily stored, and a 
DBM ARQ NAK shall be returned to the sender, who shall retransmit an exact duplicate DBM 
data block. Upon receipt of the duplicate, the receiving station shall again test the CRC. Ifthe 
CRC is successful, the data block shall be passed through as described before, the previously 
unacceptable data block should be deleted, and a DBM ARQ ACK shall be returned. If the CRC 
fails again, both the duplicate and the previously stored data blocks shall be used to correct, as 
possible, errors and to create an “improved” data block. See figure A-48 for an example of data 
block reconstruction. The “improved” data block shall then be CRC tested. If the CRC is 
successful, the “improved” data block is passed through, the previously unacceptable data blocks 
should be deleted, and a DBM ARQ ACK shall be returned. If the CRC test fails, the 
“improved” data block shall also be stored and a DBM ARQ NAK shall be returned. This 
process shall be repeated until: (a) a received duplicate, or an “improved” data block passes the 
CRC test (and the data block is passed through, and a DBM ARQ ACK is returned); (b) the 
maximum number of duplicates (such as seven or more) have been sent without success (with 
actions by the sender as described above); or (c) the operators or controllers terminate or redirect 
the DBM protocol. 


During reception of frames and DBM data blocks, it is expected that fades, interferences, and 
collisions will occur. The receiving station shall have the capability to maintain synchronization 
with the frame and the DBM data block transmission, once initiated. It shall also have the 
capability to read and process any colliding and significantly stronger (that is, readable) ALE 
signals without confusing them with the DBM signal (basic ALE reception in parallel, and 
always listening). The DBM structures, especially the DBM EXTENDED, can tolerate 
significant fades, noise bursts, and collisions. Therefore, useful information which may be 
derived from readable collisions of ALE signals should not be arbitrarily rejected or wasted. 


187 


MIL-STD-188-141B 
APPENDIX A 


The DBM constructions shall be as described herein. Within the DBM data block structure, a 
CMD DBM word shall be placed ahead of the encoded and interleaved data block itself. The 
DBM word shall alert the receiving station that a DBM data block is arriving, how long it is, 
what type of traffic it contains, what its interleaver depth is, what its message and block sequence 
is, and if ARQ is required. It shall also indicate the exact start of the data block itself (the end of 
the CMD DBM word itself) and shall initiate the reception, tracking, deinterleaving, decoding, 
and checking of the data contained within the block. The message data itself shall be either one 
of two types, binary bits or ASCII. The ASCII characters (typically used for text) shall be the 
standard 7-bit length, and the start, stop, and parity bits shall be removed at the sending (and 
restored at the receiving) station. The binary bits (typically used for other character formats, 
computer files, and cryptographic devices) may have any (or no) pattern or format, and they shall 
be transferred transparently, that is, exactly as they were input to the sending station, with the 
same length and without modification. The value of the interleaver depth shall be the smallest 
(multiple of 49) which will accommodate the quantity of ASCII or binary bits message data to be 
transferred in the DBM data block. If the message data to be transferred does not exactly fit the 
uncoded data field of the DBM block size selected (except for the last 16 bits, which are reserved 
for the CRC), the available empty positions shall be “stuffed” with ASCII “DEL” characters or 
all “1” bits. The combined message and “stuff” data in the uncoded DBM data field shall then be 
checked by the CRC for error control in the DBM protocol. The resulting 16-bit CRC word shall 
always occupy the last 16 bits in the data field. All the bits in the field shall then be Golay FEC 
encoded, on a 12-bit basis, to produce rows of 24-bit code words, arranged from top to bottom in 
the interleaver matrix (or equivalent), as shown in figure A-50. The bits in the matrix are then 
read out by columns (of length equal to the interleaver depth) for transmission. Immediately 
after the CMD DBM word, the encoded and interleaved data blocks bits shall follow in bit 
format, three bits per symbol (tone). 


The DBM BASIC data block has a fixed size (interleaver depth 49) and shall be used to transfer 
any quantity of message data between zero and the maximum limits for the DBM BASIC 
structure, which is up to 572 bits or 81 ASCII characters. It is capable of counting the exact 
quantity of message data which it contains, on a bit-by-bit basis. It should be used as a single 
DBM for any message data within this range. It shall also be used to transfer any message data in 
this size range which is an “overflow” from the larger size (and increments) DBM EXTENDED 
data blocks (which shall immediately precede the DBM BASIC in the DBM sequence of 
sending). 


The DBM EXTENDED data blocks are variable in size, in increments of 49 times the interleaver 
depth. They should be used as a single, large DBM to maximize the advantages of DBM deep 
interleaving, FEC techniques, and higher speed (than DTM or AMD) transfer of data. The 
interleaver depth of the EXTENDED data block should be selected to provide the largest data 
field size which can be totally filled by the message data to be transferred. Any “overflow” shall 
be in a message data segment sent within an immediately following DBM EXTENDED or 
BASIC data block. Under operator or controller direction, multiple DBM EXTENDED data 
blocks, with smaller than the maximum appropriate interleaver depth sizes, should be selected if 
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they will optimize DBM data transfer throughput and reliability. However, these multiple data 
blocks will require that the message data be divided into multiple segments at the sending station 
and sent only in the exact order of the segments in the message. The receiving stations must 
recombine the segments into a complete received message. When binary bits are being 
transferred, the EXTENDED data field shall be filled exactly to the last bit. When ASCII 
characters are being transferred, the EXTENDED data field may have 0 to 6 “stuff” bits inserted. 
Individual ASCII characters shall not be split between DBM data blocks and the receiving 
station shall read the decoded data field on a 7-bit basis, and it shall discard any remaining 
“stuff bits (modulo-7 remainder). 


If stations are exchanging DBM data blocks and DBM ARQs, they may combine both functions 
in the same frames. They shall discriminate based on the direction of transmission and the 
sending and destination addressing. If ARQ is required in a given direction, only one DBM data 
block shall be allowed within any frame in that direction, and only one DBM ARQ shall be 
allowed in each frame in the return direction. If no ARQ is required in a given direction, 
multiple DBM data blocks may be included in frames in that direction, and multiple DBM ARQs 
may be included in the return direction. 


As always throughout the DBM protocol, any sequence of DBM data blocks to be transferred 
shall have their KB1 sequence control bits alternating with the preceding and following DBM 
data blocks (except duplicates for ARQ, which shall be exactly the same as their originally 
transmitted DBM data block). Also, all multiple DBM data blocks transferring multiple 
segments of a large data message shall all have their KB2 message control bits set to the same 
value, and opposite of the preceding and following messages. If a sequence of multiple but 
unrelated DBM data blocks are sent (such as several independent and short messages within 
several DBM BASIC data blocks), they may be sent in any sequence. However, when sent, the 
associated KB1 and KB2 sequence and message control bits shall alternate with those in the 
adjacent DBM data blocks. 


The CMD DBM words shall be constructed as shown in table A-XXXV. The preamble shall be 
CMD (110) in bits P3 through P1 (W1 through W3). The first character shall be “b” (1100010) 
in bits C1-7 through C1-1 (W4 through W10), which shall identify the DBM “block” function. 


For DBM BASIC, EXTENDED, and NULL, when the ARQ control bit KB4 (W11) is set to “0,” 
no correct data receipt acknowledgment is required; and when set to “1,” it is required. For 
DBM ARQ, ARQ control bit KB4 is set to “0” to indicate acknowledgment or correct data block 
receipt (ACK); and when set to “1,” it indicates a failure to receive the data and is therefore a 
request-for-repeat (NAK). For DBM ARQ responding to a DBM NULL interrogation, KB4 “0” 
indicates non-participation in the DBM protocol or traffic type, and KB4 “1” indicates 
affirmative participation in both the DBM protocol and traffic type. 


For DBM BASIC, EXTENDED, and NULL, when the data type control bit KB3 (W12) is set to 
“0,” the message data contained within the DBM data block shall be binary bits with no required 


189 


MIL-STD-188-141B 
APPENDIX A 


format or pattern; and when KB3 is set to “1” the message data is 7-bit ASCII characters. For 
DBM ARQ, flow control bit KB3 is set to “0” to indicate that the DBM transfer flow should 
continue or resume; and when KB3 is set to “1” it indicates that the sending station should pause 
(until another and identical DBM ARQ is returned, except that KB3 shall be “0”). 


For DBM BASIC, EXTENDED, and NULL, when the “message” control bit KB2 (W13) is set 
to the same value as the KB2 in any sequentially adjacent DBM data block, the message data 
contained within those adjacent blocks (after individual error control) shall be recombined with 
the message data within the present DBM data block to reconstitute (segment-by-segment) the 
original whole message; and when KB2 is set opposite to any sequentially adjacent DBM data 
blocks, those data blocks contain separate message data and shall not be combined. For DBM 
ARQ, “message” control bit KB2 shall be set to match the referenced DBM data block KB2 
value to provide message confirmation. 


For DBM BASIC, EXTENDED, and NULL, the sequence control bit KB1 (W14) shall be set 
opposite to the KB1 value in the sequentially adjacent DBM BASIC, EXTENDED, or NULLs be 
sent (the KB1 values therefore alternate, regardless of their message dependencies). When KB1 
is set the same as any sequentially adjacent DBM sent, it indicates a duplicate. For DBM ARQ, 
sequence control bit KB1 shall be set to match the referenced DBM data block or NULL KB1 
value to provide sequence confirmation. 


When used for the DBM protocols, the ten DBM data code (BC) bits BC10 through BC1 (W15 
through W24) shall indicate the DBM mode (BASIC, EXTENDED, ARQ, or NULL). They 
shall also indicate the size of the message data and the length of the data block. The DBM 
NULL BC value shall be “0” (0000000000), and it shall designate the single CMD DBM NULL 
word. The DBM EXTENDED BC values shall range from “1” (0000000001) to “445” 
(0110111101), and they shall designate the CMD DBM EXTENDED word and the data block 
multiple (of 49 INTERLEAVER DEPTH) which defines the variable data block sizes, in 
increments of 588 binary bits or 84 ASCII characters. The DBM BASIC BC values shall range 
from “448” (0111000000) to “1020” (1111111100), and they shall designate the CMD DBM 
BASIC word and the exact size of the message data in a fixed size (INTERLEAVER DEPTH = 
49) data block, with up to 572 binary bits or 81 ASCII characters. The DBM ARQ BC value 
shall be “1021” (1111111101), and it shall designate the single CMD DBM ARQ word. 


NOTES: 

1. The values “446” (0110111110) and “447” (0110111111) are reserved. 

2. The values “1022” (1111111110) and “1023” (1111111111) are reserved until standardized 
(see table A-X XXIV). 


A.5.8 AQC (optional) (NT). 
AQC-ALE is designed to use shorter linking transmissions than those of baseline second 
generation ALE (2G ALE) described previously in this appendix. AQC-ALE uses an extended 
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version of the 2G ALE signaling structure to assure backward compatibility to already fielded 
radios. Special features of AQC-ALE include the following: 


e The signaling structure separates the call attempt from the inlink-state transactions. 
This allows radios that are scanning to detect and exit a channel that is carrying traffic 
that is of no interest. 


e The address format is a fixed form to allow end of address detection without requiring 
the last word wait timeout. 


e Control features distinguish call setup channels from traffic carrying channels. 


e Local Noise Reports are inherent in the sound and call setup frames to minimize the 
need to sound as frequently. 


e Resources that are needed during the linked state can be identified and bid for during 
the link setup. This provides a mechanism to bid for needed resources during linking. 


A.5.8.1 Signaling structure (NT). 
The AQC-ALE signaling structure is identical to that described previously in this appendix, 
except as provided below and in the remaining subsections of this section: 


e The AQC-ALE word is encoded differently (see A.5.8.1.1). 


e A PSK tone sequence may optionally be inserted between AQC-ALE words during 
calling handshakes or sounds (see A.5.8.1.6). All compliant implementation of AQC- 
ALE shall correctly process the AQC-ALE words in calling handshakes and sounds 
whether or not such PSK tone sequences are present, and whether or not the 
implementation can extract useful channel data from such PSK tone sequences. 


A.5.8.1.1 AQC-ALE word structure (NT). 

The AQC-ALE word shall consist of a three-bit preamble, an address differentiation flag, a 16-bit 
packed address field, and a 4-bit Data Exchange field. These fields shall be formatted and used 
as described in the following paragraphs. Every AQC-ALE word shall have the form shown in 
figure A-52, AQC-ALE Word. The data values associated with a particular AQC-ALE word are 
defined by the context of the frame transmission (see A.5.8.2). 


A.5.8.1.1.1 Packed address (NT). 

AQC-ALE packs the 21 bits representing three address characters in the 38-character ASCII 
subset into 16 bits. This is performed by assigning an ordinal value between 0 and 39 to each 
member of the 38-character subset. Base 40 arithmetic is used to pack the mapped data into a 16- 
bit number. The ASCII characters used for addressing shall be mapped to the values defined in 
table A-XX XVI, Address Character Ordinal Values, with character 1's value multiplied by 1600, 
Character 2’s value multiplied by 40, and Character 3’s value multiplied by 1. The sum of the 
three values shall be used as the 16-bit packed address (see example below). 
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15: TAL V3) 2° be TO 9 = Be P26 eS AL 3 De 


3 2 i 0 
Packed Address , 1600*C1 + 40*C2 + C3 


mo Packed Address Bits Data Exchange 


5 6 7 8 9 10 11 12 13 14 15 1617 18 19 20 21 22 
FIGURE A-52. AQC-ALE data exchange word. 


TABLE A-XXXVI. AQC address character ordinal value. 


13 to 38 


_ 39 
(Underscore) 


Note: The “*” and “_” characters are not part of the standard ALE ASCII-38 character set. 
These characters shall not be used in station addresses in any network that is required to 
interoperate with stations that support only baseline 2G ALE. 


Example: 
Using table A-XXXVI, the address 'ABC' would be computed as: 


(Value(‘A') * 1600) + (Value(‘B')* 40) + Value('C’) 
which is 
( 13 * 1600 )+( 14 *40 ) + 15 =~ 21,375 


The smallest valued legal address is "000" for a packed value of » 1,641 
A legal address such as "ABC" would have a packed value of = 21,375 
The largest valued legal address is "ZZZ" for a packed value of } 62,358 


A.5.8.1.1.2 Address differentiation flag (NT). 
Bit 4 of the AQC-ALE word shall be a copy of the most significant bit of the 16-bit packed 


address. This combination results in no legal address in AQC-ALE being legal in baseline 2G 
ALE and vice versa. The packed address shall occupy the next 16 bits of the 21-bit data portion 
of the address. 
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A.5.8.1.2 Preambles (NT). 
The preambles shall be as shown in table A-XX XVII AQC-ALE word types (and preambles) 


TABLE A-XXXVII. AOC-ALE word types (and preambles). 


TOU fT See table AV 
[CMD See table AWE 


PART2 100 direct routing indicates this is the second part of the 
x AQC-ALE address 


eat —___ [SeetableA-VI 
pas |-- ~—C~Y See ttable A-VI. ss ss A-VIIL 


information extend information being sent 
duplication and Used only in message section to 
extension of extend information being sent 
information 


A.5.8.1.2.1 TO (NT). 
This preamble shall have a binary value of 010 and is functionally identical to the TO 


preamble in A.5.2.3.2.1. The AQC-ALE TO preamble shall represent the first of two words 
identifying the address of the station or net. 


A.5.8.1.2.2 THIS IS (TIS) (NT). 

This preamble shall have a binary value of 101. The preamble is functionally identical to the 
TIS. preamble in A.5.2.3.2.2. The AQC-ALE TIS preamble identifies the AQC-ALE word as 
containing the first three characters of the of the calling or sounding station address. 


A.5.8.1.2.3 THIS WAS (TWAS) (NT). 

This preamble shall have a binary value of 011. This preamble is functionally identical to the 
TWAS preamble in A.5.2.3.2.3. The AQC-ALE TWAS preamble identifies the AQC-ALE word 
as containing the first three characters of the of the calling or sounding station address. 
A.5.8.1.2.4 PART2 (NT). 

This preamble shall have a binary value of 100. This preamble is shared with the baseline 2G 
ALE preamble of FROM. This preamble identifies the second set of three characters in an AQC- 
ALE address. This preamble shall be used for the second word of every AQC-ALE packed 
address transmission. 


A.5.8.1.2.5 INLINK (NT). 
This preamble shall have a binary value of 001. This preamble is shared with the baseline 2G 


ALE preamble of THRU. This preamble shall be used by AQC-ALE whenever a transmission to 
stations already in an established link is required. This preamble identifies the AQC-ALE word 
as containing the first three characters of the transmitting station address. This preamble may also 
be used in the acknowledgement frame of a three-way handshake as described in A.5.8.2.3. 
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A.5.8.1.2.6 COMMAND (NT). 
No Change to A.5.2.3.3.1 


A.5.8.1.2.7 DATA (NT). 
See A.5-2.3.4.1. In the AQC-ALE word, this preamble never applies to a station address. 


A.5.8.1.2.8 REPEAT (NT). 
See A.5-2.3.4.2. In the AQC-ALE word, this preamble never applies to a station address. 


A.5.8.1.3 AQC-ALE address characteristics (NT). 


A.5.8.1.3.1 Address size (NT). 
Addresses shall be from 1 to 6 characters. 


A.5.8.1.3.2 Address character set (NT). 
The address character set shall be the same ASCII-38 character set as for baseline 2G ALE. 


A.5.8.1.3.3 Support of ISDN (option) (NT). 

To support an ISDN address requirement, the station shall be capable of mapping any 15 
character address to and from a 6 character address for displaying or calling. This optional 
mapping shall be available for at least one Self Address and all programmed Other Addresses in 
the radio. 


A.5.8.1.3.4 Over-the-air address format (NT). 

A two AQC-ALE word sequence shall be broadcast for any AQC-ALE address. The “@” shall 
be used as the stuff character to complete an address that contains fewer than six characters. The 
sequence shall be an AQC-ALE word with the preamble TO, TIS, TWAS, or INLINK for the 
first three characters of the address followed by an AQC-ALE word with the preamble PART2 
for the last three address characters. 


A.5.8.1.4 Address formats by call type (NT). 


A.5.8.1.4.1 Unit addresses (NT). 
A unit or other address shall be from one to six characters. 


A.5.8.1.4.2 StarNet addresses (NT). 
A StarNet address shall be from one to six characters. 


A.5.8.1.4.3, Group addresses (NT). 
This feature is not applicable to AQC-ALE. 
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A.5.8.1.4.4 AllCall address (NT). 

AQC-ALE AllCall address shall be six characters. The second three characters of the AllCall 
address shall be the same as the first three characters. Thus, a global AllCall sequence would 
look like: 


TO-@?@|PART2-@?@. 
A.5.8.1.4.5 AnyCall address (NT). 
AQC-ALE AnyCall address shall be six characters. The second three characters of the AnyCall 
address shall be the same as the first three characters. Thus, a global AnyCall sequence would 
look like: 


TO-@@?|PART2-@@?. 


A.5.8.1.5 Data exchange field (NT). 

The 4-bit data exchange field shall be encoded as described in table A_XXXVIII and the 
following paragraphs. The use of the various encodings DE(1) through (9) shall be as shown in 
the figures for the Sound, Unit call, Starnet call, All call, and Any call in the respective 
subsections of A.5.8.2. 


NOTE: A station may use the contents of the data exchange field to further validate the 
correctness of a given frame. 


TABLE A-XXXVIII. Data exchange definitions. 


| CT Bits | Bit? =| Bit [Bit [Description 
egy) ft} ft ft No Data Available —_____| 


DE(2) Number of TOs Left in Calling Cycle 
Section 


DE(3) = a a = Inlink Resource List Expected 
DE(4) Pe a Nee nde 


LOA < LQA Minimum from 1 bit spare, 3 bits of LQA variance 
DEG et] ed Mean> data 


|DE(6) | =x [LQAMeasurementIndex Measurement | LQA Measurement Index sd 


DE(7) 4 EE Number of Tis/Twas left in Sound 


DE(8) Ack This a of Conn Preambles> Most Significant Bits of the Inlink 
Transaction Code 


DE(9) I'm Inlink Least significant 4 bits of Inlink 


A.5.8.1.5.1 DEC) no data available (NT). 

DE(1) shall be sent in the TIS word in the conclusion of a Call frame. All data bits shall be set to 
ls. 

A.5.8.1.5.2 DE(2) number of to’s left in calling cycle (NT). 

DE(2) shall be sent in every AQC-ALE word that contains a TO preamble. In a Call frame, the 
DE(2) field shall indicate the remaining number of TO preambles that remain in the frame. This 
is an inclusive number and when set to a value of 1 the next address shall be the caller’s address 
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using a TIS or TWAS preamble. When the remaining call duration would require a count greater 
than 15, a count of 15 shall be used. 


A value of 0 shall be used in in the Response frame and Acknowledgement frame when a single 
address in required. DE(2) shall count down to 1 whenever multiple addresses are transmitted in 
an address section. 


A.5.8.1.5.3 DE(3) Inlink resource list (NT). 

DE(3) shall be sent in the PART 2 word that follows each TO word. The DE(3) field shall 
indicate the type of traffic to be conveyed during the Inlink state, using the encodings in table 
AXXXIX. Values not specified in the table are reserved, and shall not be used until 
standardized. 


Upon receipt of the INLINK Resource List in the Call, the called station shall determine whether 
the station can operate with the desired resource. When responding to the call, the called station 
shall honor the requested resource whenever possible. If the resource requested is unavailable, 
the called unit shall respond with an alternate resource that is the best possible alternative 


resource available to the receiver. This information is provided in the Response frame of a 
handshake. 


By definition, when the calling station enters an Inlink state with the called station, the calling 
station accepted the Inlink resource that the called station can provide. 


TABLE A-XXXIX. Inlink resource list. 


| 0) | ClearVoice 

High Fidelity Digital (HFD) Voice 

Reserved 

| 6 [Reserved CNA 
| KY-100 Data Security Active | 
[Reserved 


15 Undeclared Traffic. Usually a mixture. Always Acceptable 


A.5.8.1.5.4 DE(4) local noise report (NT). 
DE(4) shall be sent in the PART 2 word that concludes a Call frame and in every PART 2 word 
in a Sounding frame. The Local Noise Report contains information which describes the type of 
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local noise at the sender’s location. The Local Noise Report provides a broadcast alternative to 
sounding that permits receiving stations to approximately predict the bilateral link quality for the 
channel carrying the report. An example application of this technique is networks in which most 
stations are silent but which need to have a high probability of linking on the first attempt with a 
base station. A station receiving a Local Noise Report can compare the noise level at the 
transmitter to its own local noise level, and thereby estimate the bilateral link quality from its 
own LQA measurement of the received noise report transmission. The report includes a mean 
and maximum noise power measured on the channel in the past 60 minutes with measurement 
intervals at least once per minute. 


The Local Noise Report shall be formatted as shown in figure A.5.8-5. Units for the Max and 
Mean fields are dB relative to 0.1 uV 3 kHz noise. The Max noise level shall be the amount of 
distance from the Mean that the local noise was measured against. When averaging is used, 
standard rounding rules to the integer shall apply. By comparing the noise levels reported by a 
distant station on several channels, the station receiving the noise reports can select a channel for 
linking attempts based upon knowledge of both the propagation characteristics and the 
interference situation at that destination. For a more detailed local noise report, a station may 
broadcast the ALE Local Noise Report command in the message section. When deriving the 
average noise floor, signals which can be recognized shall be excluded from the power 
measurement. 


TABLE A-XL. Local noise report. 


No Data 
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A.5.8.1.5.5 DE(5) LQA variation (NT). 

DE(5) shall be sent in the TIS or TWAS word in the conclusion of AQC-ALE Response and 
Acknowledgement frames. It shall report the signal quality variation measured on the 
immediately preceding transmission of the handshake. 


Whenever an AQC-ALE or ALE word is received, a signal noise ratio (SNR) sample shall be 
computed. This measurement can be used to determine the capacity of the channel to handle 
traffic. Because several types of signaling protocols may be used while in the linked state, it is 
important that this measurement be applicable to a wide variety of signaling structures. The 
DE(5) LQA Data Exchange word provides feedback as to the value of the measured signal. 


During receipt of a AQC-ALE or ALE signal, an SNR measurement shall be taken at least every 
Tw (non-redundant word period). Three characteristics shall be collected: 

1. A Mean SNR signal shall be derived 

2. A Minimum SNR value during the frame shall be recorded 


3. Rapid Change Boolean, when set 1, shall indicate more than 40 percent of the 
measurements varied greater than +3 dB from the mean SNR. 


pT Bit3 | Bit? | Biti | BitO [Description 


Rapid <LQA Minimum from | one bit spare, 3 bits of LQA 
DE(5) Change LQA Mean> variation data 


Items 2 and 3 of the LQA calculation are reported in this data exchange field. This field shall be 
set to all 1’s when the LQA measurement value in DE(6) indicates that no SNR value was taken. 
Table A-XLT shall be used to encode the magnitude of lowest value SNR difference from the 
Mean. 


TABLE A-XLI. Magnitude of minimum SNR from mean SNR. 


Magnitude from SNR MEAN 
10 ~=———S=*T «difference <= 6 dB 


6 < difference <= 12 dB 
12 < difference <= 18 dB 
> 18 dB drop from SNR Mean 


A.5.8.1.5.6 DE(6) LQA measurement (NT). 
DE(6) shall be sent in the PART 2 word in the conclusion of AQC-ALE Response and 


Acknowledgement frames. The Link Quality Measurement contains the predicted quality of the 
channel to handle traffic. This value may be used as a first approximation to setting data rates for 
data transmission, determining that propagation conditions could carry voice traffic, or directing 
the station to continue to search for a better channel. (See A.5.8.1.5.5 for a description of the 
LQA.) This can also be used to determine which channels are more likely to provide sufficient 
propagation characteristics for the intended Inlink state traffic. Table 
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A-XLI shall be used to encode the measured mean SNR value. An additional column is 
provided suggesting possible channel usage for the given SNR value. 


TABLE A-XLII. LQA scores. 


Value Potential Channel Usage 
Choose another channel 
use 50 to 75 bps data 
use 50 to 75 bps data 
use 150 bps data 
use 300 bps data 
use 300 bps data 

9 < SNR <= 12 use 1200 bps data, could carry voice, digital voice, 
eed KY-100 data, secure digital voice 
use 1200 bps data, could carry voice 

15 <SNR <= 18 use 2400 bps data, could carry voice 

18 < SNR <= 21 use 2400 bps data, could carry good quality voice, 
HFD Voice, Secure HFD Voice 
10 21<SNR <= 24 use 4800 bps data, could carry high quality voice 
11 use 4800 bps data, could carry poor quality voice 
12 Very high data rates can be supported (9600 baud) 
13 
14 
15 Value in DE(S5) shall be ignored 


A.5.8.1.5.7 DE(7) number of Tis/Twas left in sounding cycle (NT). 

While transmitting the sounding frame, DE(7) shall be sent in each TIS/TWAS word to identify 
the remaining number of TIS/TWAS words that will be transmitted in the frame. This is an 
inclusive number and when set to a value of 1, only one PART2 word remains in the frame. 


| Value | 
jo 
8 
|10 
a 
p12 
|13 
p14 
[15 


When the sound duration would require an initial count greater than 15, a count of 15 shall be 
used until the count can correctly decrement to 14. From this point, DE(7) shall count down to 1. 


A.5.8.1.5.8 DE(8) inlink data definition from INLINK (NT). 
Inlink Event transaction definitions are defined by 2 data exchange words. DE(8) shall be used 


when the INLINK preamble is used, while DE(9) shall be used for the second half of the address 
begun with the INLINK preamble. 


| | Bits | Bit2 [| Bitt [| BitO |Description 


DE(8) AckThis <# of Command Preambles> Most Significant Bits of the 
Inlink Transaction Code 


A.5.8.1.5.8.1 Acknowledge this frame (NT). 
Data Bit3, ACK-THIS, when set to 1, shall indicate that the stations which are linked to the 


transmitting station are to generate an ACK Inlink message in response to this frame. If the 
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address section of an Inlink transaction is present, then only the addressed stations in the link are 
to respond. The responding station Inlink event shall return a NAK if any CRC in the received 
message fails, otherwise the Inlink event shall be an ACK. When Data Bit3 is set to 0, the 
transmitting station is broadcasting the information and no response by the receiving stations is 
required. 


A.5.8.1.5.8.2 Identify command section count (NT). 

Data Bits 0-2 represent the number of command sections that are present in the frame. A value 
of 0 indicates no command sections are present, i.e., the frame is complete when the immediately 
following PART2 address word is received. A value of 1 indicates that 1 command section is 
present. Up to seven command sections can be transmitted in one Inlink event transaction. 


A.5.8.1.5.9 DE(9) Inlink data definition from PART2 (NT). 
Inlink Event transaction definitions are defined by 2 data exchange words. DE(9) is used for the 
second half of the address begun with the INLINK preamble. 


| Bits | Bit? | Bit! [| BitO |Description 


DEQ) I'm Inlink Least significant 4 bits of Inlink 


A.5.8.1.5.9.1 LAM remaining in a link state (NT). 

Data Bit3, I'mInlink, when set to 1, shall indicate that the transmitting station will continue to be 
available for Inlink transactions. When set to 0, the station is departing the linked state with all 
associated stations. It shall be the receiver 's decision to return to scan or perform other overhead 
functions when a station departs from a link state. All Inlink event transactions should set this to 
'l' when the members of the link are to remain in the linked state. 


Valid combinations of data bit ACK-THIS and I'mInlink are defined in table A-XLIII. 


TABLE A-XLIII. Valid combinations of ACK-This and I'm Inlink. 
ay ae eee eee 


po Station remaining in linked state 
po Not vatiid._A station cannot leave a link and expect a response _| 


A.5.8.1.5.9.2 Inlink event transaction code (NT). 
Data Bits 0-2 represent the type of Inlink event that is being transmitted. Table A-XLIV shall be 


used to encode the types of Inlink events. The Operator ACK/NAK and AQC-ALE Control 
Message sections are described in A.5.8.3. 
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TABLE A-XLIV. DE(9) inlink transaction identifier. 


poo | Reserved 
1 MS_ 141A Section Definition. Each section 1to7 

| | ietiecemnmictmscre |? 

Pp 2 | ACK 'ng Last Transaction 

| 3 | NAK'ngLLast Transaction TO 


| 4 |) | Directed Link Terminate 
| 6 |) @) | AQC-ALE ControlMessage to 
fee il i Mesenved 


1. Requires that an address section (To,Part2) was received in the frame. 
2. Optional Transaction Code. 


A.5.8.1.6 PSK tone sequence (optional) (NT). 


In any frame of a calling handshake or sounding transmission, the transmitting station may emit 
an optional PSK tone sequence to provide an early measurement of the channel characteristics 
relative to a PSK type signaling waveform. 


A.5.8.1.6.1 PSK tone sequence placement (NT). 


The optional PSK tone sequence for link quality may be inserted after the last tone associated 
with any PART2 AQC-ALE word and prior to the first FSK tone of the following AQC-ALE 
word (if any). The 26.67 ms PSK tone sequence shall be preceded by 8 ms of guard time and 
followed by 21.33 ms of guard time, for a total duration of 56 ms (seven symbol periods of the 
2G ALE FSK waveform). 


A.5.8.1.6.2 PSK tone sequence generation (NT). 
The PSK tone sequence shall be identical to the 26.67 ms preamble for Burst Waveform 2 (see 


C.5.1.5). 


A.5.8.2 AQC-ALE frame structure and protocols (NT). 
A.5.8.2.1 Calling cycle (NT). 


The calling cycle frame is used when the caller is attempting to reach a station that is scanning. 
Sufficient address words are repeated continuously until the scanning radio has had ample 
opportunity to stop on the channel. Other receivers, upon hearing an address, may recognize the 
presence of an ongoing call and skip processing the channel until the handshake is completed. 


The calling cycle shall be composed of the target address broadcast for at least the period defined 
as the call duration for the radio, followed by the target address followed by the caller's (source) 
address. Data exchange values shall be per the specific type of call being attempted. When the 
call duration is not evenly divisible by 2 Trw, then an additional full address may be transmitted. 
When an entire address is not used to complete a fractional portion of the call duration, the caller 
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shall begin the transmission with the second half of the target address using the PART2 
preamble. In this case, the LP word number shall be 1. 


When the radio is programmed to automatically derive the call duration, the equation shall be: 
Number of Channels * 0.196 


Table A-XLV specifies minimum and maximum number of words used for the scanning cycle 
section of a call. The total number of words used for calling is four additional words. The unit 
call time column presents the maximum time to complete a unit call as measured from the first 
tone transmitted by the caller to the last tone transmitted by the caller in the Acknowledgement 
frame. Users will see times greater than these due to call setup time, caller tune time, listen 
before call, and link notification delay; these may add several seconds to the response time seen 
by a user. 


TABLE A-XLV. Scanning part duration using automated calculation. 


Channels AQC-ALE Minimum AQC-ALE Maximum Call Time in 
Scan Trw Scan Trw Seconds 
fe 


| 


a 
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A.5.8.2.2 Unit call structure (NT). 

A unit call in AQC-ALE follows the same principles as a standard ALE unit call with the 
following changes. In the Leading Call section of the Call and Response, the address shall 
appears once instead of twice. In the Acknowledgement frame, only the conclusion section shall 
be sent. See figure A-53 for an example of a unit call sequence from SOURCE to TARGET. 


e See A.5.8.2.1, Calling Cycle to determine the maximum number of words to send 
during the scanning call portion of the Call. 


e The optional PSK tone sequence shall be available during any leg of the handshake. 


e An Inlink Event Transaction shall be used in lieu of the Acknowledgement frame 
when ALE data traffic is available for the Inlink State in AQC-ALE. 


Channel* 
Call Probe 
Preamble Tis 
Address SOU 
Data Type] _DE(2)=4| DE(1 


Lp Wrdé# ** ay 


Wao en, @ 1 ~L 
psk tone mae tone 
sequence sequence 


Response 


Preamble 
Address 


Data Type , 


Lp Wrd#** 0 one, 
sequence sequence 


Acknowledge 


Preamble * Scanning Rate approximately 200 ms 
Address Grayed Area Indicates Optional Transmissions 
Data Type ** Follows LP Word Number rules for a frame 


Lp Wrd# ** oe 
sequence 


Preamblelinins  [Part2 eommand|data___repeat__[__._.__oommand] 

addressjSOU_| RCE | |... | | crc 
Data Type|__DE@_ deal | 
0 1 


Lp Wrd# * 


FIGURE A-53. Example of unit call format. 


A.5.8.2.3 Star net call structure (NT). 

The call probe shall be identical to a Unit call where the star net address replaces the unit 
address. The Slotted Response portion shall always use a two word address for the TO and TIS 
addresses. Just as in Baseline 2G ALE, the slotted response shall be 5 Tw wider than the 6 Tw 
needed to transmit the TIS/TWAS address. Slot 0 shall be 17 Tw to accommodate a non-net 
member participating in the call. Slot 1 and all remaining slots shall be 11 Tw wide. No LQA 


203 


MIL-STD-188-141B 
APPENDIX A 


information shall be emitted in the Acknowledgement portion of the Start Net Call except as 
provided through the data exchange bits. The optional PSK tone sequence shall be available 
during any frame of the handshake. The slot width does not change, even when the optional PSK 
tone sequence is used. 


The Data Exchange values shall be per figure A-54. 


Channel* 
Call Probe 


Preamble 
Address 
Data Type 


fro Pana [fo [Para [fo [Pana fo ‘(Panta [ris 
RCE 


YDE(2)=4| 
11 


Lp Wrd# * 


Response 
Preamble 
Address 
Data Type 
Lp Wrd# ** 


lee og Po — fo a — 
SOU_| RCE | TAR | GET MEM | BER 


0 


5I 
sequence 


* Scanning Rate approximately 200 ms 


ROA oe 

ae cn a 
ST | NET pSsOuT | RCE 
| pe2)=0l ea) DEL CDE) 


Alternate Leg 3 
Preamble|Inlink Part2 lcommand|data_repeat |. [commana | 
Address[SOU_ | RCE | .. | | CRE 
Data Type|__pe@| pel | [ | | | 


Lp Wrd# * 


Preamble 
Address 
Data Type 
Lp Wrd# ** 


Grayed Area Indicates Optional Transmissions 
** Follows LP Word Number rules for a frame 


FIGURE A-54. Example of StarNet format. 


An Inlink Event frame may be used for the Acknowledgement frame. Slots 1 and beyond may be 
expanded by fixed number of Trw for certain types of AQC-ALE Inlink Messages. 


A.5.8.2.4 AllCall frame formats (NT). 
A station placing an AllCall shall issue the call using the calling cycle definition in A.5.8.2.1. 


The actions taken shall be as described for baseline 2G ALE AllCalls. The Data Exchange 
values shall be per figure A.-55, AllCall Frame Format. Selective AllCall shall be supported. 
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Channel* 
Call Probe 


1 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 
Preamble|To Part2 To Part2 To Part2 To Part2 Tis Part2 
Address}| @A@ | @A@ | @A@ | @A@ | @A@ | @A@ | @A@ } @A@ | SOU | RCE 
Data TypeL_DE(2)=4 DE(3)|_DE(2)=3 DE(3 DE(2)=2 DE(3)|_DE(2)=1 DE(3 DE(1 DE(4 


2 


Lp Wrd# ** 1} 9 1} Q 1} "0 1). Bh 
sequence sequence sequence sequence sequence 


FIGURE A-55. Example AllCall frame format. 


A.5.8.2.5 AnyCall frame formats (NT). 

A station placing an AnyCall shall issue the call using the calling cycle definition in A.5.8.2.1. 
The actions taken shall be a described for baseline 2G ALE AnyCalls except that the Slot width 
shall be fixed at 17 Tw. The leading address section and conclusion shall be used for each 


slotted response. The Data Exchange values shall be per figure A-56. Selective AnyCall and 
Double Selective AnyCall shall be supported. 


Channel* 
Call Probe 
Shea 
Address] @@A | @@A| @@A| @@A| @@A | @@A| @@A 
Data Type__DE(2)=4 DE(3 DE(2)=3 DE(3. DE(2)=2 DE(3 DE(2)=1 DE(3 DE(1 DE(4 


Lp Wrd# ** 14 1p oan, 0 1h oo 14 3 
sequence sequence sequence sequence sequence 


Response 


Preamble To [Part2 tis [Panta | 


Data Type DE(2)=0 DE(3 DE(5 DE(6)|[5 TWs 
0 H 


Lp Wrd# ** 13 : 3h 


Acknowledge 
Preamble 


adcress| ANY | O1A | _... | ..._| ANY | 054 
Data Type 


Lp Wrd# ** 


* Scanning Rate approximately 200 ms 


Grayed Area Indicates Optional Transmissions 
** Follows LP Word Number rules for a frame 


FIGURE A-56. Example AnyCall frame formats. 


An Inlink Event frame shall not be used for the Acknowledgement frame. 
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A.5.8.2.6 Sounding (NT). 

The sounding cycle shall be composed of the station's address broadcast for at least the period 
defined as the sound duration for the radio. Data exchange values shall be as denoted in figure 
A-57. When the call duration is not evenly divisible by 2 triple-redundant word times, then the 
an additional full address may be transmitted. When an entire address is not used to complete a 
fractional portion of the sound duration, the caller shall begin the transmission with the second 
half of the target address using the PART2 preamble. In this case, the LP word number shall be 
1. As shown in figure A-57, the LP word number shall toggle between 0 and 1. 


When the radio is programmed to automatically derive the sound duration, the equation shall be: 
Number of Channels * 0.196 + 0.784 


See table A-58 for the minimum and maximum number of Trw to broadcast automatically. 


Sound Probe 
Channel* 


3 
Preamble ae CER are aaa was rt2 las eae 
Data TypeL_DE(7 =4 pE(ay DE(7 =3 peta) —DE(7 =2 DE(7 = pea 
LP Wrd#** QA eA QT 
ee uence Ea uence eres uence eee uence 


* Scanning Rate approximately 200 ms 


Grayed Area Indicates Optional Transmissions 
PSK tone sequence ** Follows LP Word Number rules for a frame 


FIGURE A-57. Example sounding frame format. 


A.5.8.2.7 Inlink transactions (NT). 

AQC-ALE stations shall have the capability to transfer information within the Inlink state of the 
radio. A special purpose frame is defined for the purpose of separating link establishment 
transactions from transactions that occur during the Inlink state. Two types of Inlink transactions 
are defined, Inlink Event and Inlink Event Sequence. Either transaction can have an optional 
address section appended to the beginning of the frame. This optional address section indicates 
that the transaction is targeted at the addresses defined in this section of the frame. 


The Inlink frame uses Data Exchange DE(8) and DE(9). DE(8) informs the recipient of the type 
of transaction and whether this frame needs to be acknowledged. See A.5.8.3.8. DE(9) data 
content indicates to the caller the exact form of the data and identifies if the sender intends to 
remain in the linked state with all those represented in the address section of the frame. When 
the address section is omitted, the frame shall be targeted to all stations currently linked with the 
transmitting station. See A.5.8.3.9. 
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The data Exchange values shall be per figure A-58. This figure outlines the general format of 
both types of Inlink transaction events. 


InLink Event 
Preamble|to InLink Part2 
Address|Address i SOU RCE * Scanning Rate approximately 200 ms 
Data Type|DE(2 DE(8& DE(Q Grayed Area Indicates Optional Transmissions 
Lp Wrd# ** ** Follows LP Word Number rules for a frame 


InLink Event Sequence 


Preamble|to Part2 Command |Data Repeat Data Repeat Command 
Address|Address i RCE | CTRL | V(2) | V(3) | V(4) | V(5) CRC 
Data Type[DE(2 DE(Q 16 bit 
1 2 3 4 5 6,0 7,1 ; 


Lp Wrd# ** 


Address Section 


Preamble|To Part2 To Part2 To Part2 To Part2 
Address| MBR | 001 52 me ae te MBR |} 004 
Data TypeL_DE(2)=4] DE(3)=15| DE(2)=3] DE(3)=15} DE(2)=2}] DE(3)=15| DE(2)=1| DE(3)=15 

1 2 3 4 5 6,0 1a. 


Lp Wrd# ** 


FIGURE A-58. Example inlink transaction TRW sequences. 


A.5.8.2.7.1 Inlink transaction as an acknowledgement (NT). 

The Inlink Event or the Inlink Event Sequence shall be used as the Acknowledgement frame of a 
handshake whenever the calling radio has a message for the radios entering the Inlink state. If 
the INLINK preamble is replacing a TIS preamble indicating that the radios were to remain in an 
Inlink state, then the TM LINKED bit shall be set to 1. Ifa TWAS preamble would normally be 
used for this transmission, the 1M LINKED bit shall be set to 0. Thus, the calling station can 
minimize over the air time for any transaction by judicious use of Inlink state and associated 
control bits. 


A.5.8.2.7.2 CRC for Inlink event sequences (NT). 

As seen in figure A-58, a command section of an Inlink event sequence shall consist of the 
COMMAND preamble, followed by the data associated with the command using the preambles 
DATA and REPEAT. The Inlink event sequence frame shall be terminated with a COMMAND 
preamble containing the CRC of the data contained in all words starting with the first 
COMMAND preamble. This CRC shall be computed exactly as the CRC for a standard ALE 
DTM (See A.5.6.1). The receiver shall maintain a history of failed CRC. The history may be 
displayed to the operator or used in channel selection algorithms for follow-on traffic. 


A.5.8.2.7.3 Use of address section (NT). 
The address section of a Inlink transaction, when present, shall indicate that the addressed 
stations in the link are to react to the information contained in the message section. 
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A.5.8.2.7.4 Slotted responses in an Inlink state (NT). 

When an acknowledgement has been requested, each radio in the address section shall be 
assigned a response slot in the same manner as a standard ALE group call. The slot width shall 
be as specified for AQC-ALE StarNet call, A.5.8.2.4. When the address section contains a 
StarNet address, the slot assignments shall be per the StarNet definition. When no slot 
assignment can be determined and an acknowledgement is requested, the receiving radio shall 
respond as quickly as possible. 


Slotted responses shall use an Inlink transaction frame beginning with the INLINK preamble. 
The address section shall not be permitted in the slotted response. When a the transmitting 
station issues a message that requires a responding message, such as time-request to Time-is, the 
slot widths for slot 1 and greater shall automatically expand by a fixed number of Trw to satisfy 
the response. 


When a response could be variable in length, the maximum slot width shall be used. The 
maximum width in Tw for an Inlink transaction shall be 44 Tw. This could represent an AMD 
message of up to 27 characters. 


A.5.8.3 AQC-ALE orderwire functions (optional) (NT). 

The Operator ACK/NAK and AQC-ALE Control Message sections are described below. These 
functions may only appear in frames containing INLINK transactions, and may never be used in 
baseline 2G ALE frames. 


A.5.8.3.1 Operator ACK/NAK transaction command section (optional) (NT). 

This optional message section is a means to poll every station to determine if a site is currently 
manned. The operator must respond to the request for acknowledgement in a timely manner. 
AMD messages formatted in accordance with table A.5.8-11 Operator ACK/NAK shall be used 
to define the values and meaning of the message. When a request for ACK is received, the 
operator shall have 15 seconds to respond. The ACK message shall be sent immediately as an 
Inlink Event if the operator responds. If no response from the operator occurs the receiving 
station shall emit an Operator NAK response Inlink Event. 


TABLE A-XLVI. Operator ACK/NAK command. 


AMD eee a ae to be Taken 
eee Content 


"REQ" (bees ce eee station should notify operator that a response 
to this message is required. The response must occur 
within 15 seconds. 


The operator acknowledges receipt of last Inlink event. 
The operator failed to respond to the last Inlink event. 
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A.5.8.3.2 AQC-ALE control message section (optional) (NT). 

Table A-XLVII defines the values used to declare a AQC-ALE control message. When sending 
these commands, all commands in the frame shall be AQC-ALE control messages. Table A- 
XLVI defines which message types in an AQC-ALE message section are mandatory for all 
implementations of AQC-ALE and which messages are optional for AQC-ALE implementations. 


TABLE A-XLVII. AQC-ALE control message section word sequences. 


P| in AMD Dictionary Message | Mandatory 
a 


As seen in figure A-59, each word with a COMMAND preamble contains a 5-bit MsfID field to 
define the type of control message present. Because ALE orderwire functions are still allowed, 
MsgID values greater than 7 are not allowed, as these would overlap with existing ALE 
orderwire commands. 


Size in Bits 16 


Content Message Content Word 1 


Binary Value 
Bit Numbers 


Size in Bits 


Content 


Binary Value 
Bit Numbers 


Size in Bits 


Content 


Binary Value 
Bit Numbers 


FIGURE A-59. Generalized AQC-ALE control message format. 


A.5.8.3.2.1 AMD dictionary message (NT). 

When a message section can be translated into a dictionary and all stations linked are using 
AQC-ALE, an AMD message may use the dictionary word as provided in table A-XLVIII. Each 
character in the AMD message will represent itself or a word/phrase found in one of three look 
up tables. Because messages are short, when a transmission word is lost, the complete message 
could be rendered meaningless if a bit packing approach was used. This method shall consist of 
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a series of 7-bit values. This is the same size as currently used for an AMD message. At a 
minimum, a radio shall provide lookups for values 2 through 95. A mapped entry can be of any 
length. Every radio communicating with packed AMD formats must use the same programmed 
values for words or confusion in the message will result. Messages should be displayed in their 
unpacked form as looked up or optionally with curly braces around the numeric value of the 
lookup, i.e. {2.5} would indicate word is in Dictionary Set 2 at index position 5. (See figure A- 
60 for the format of an AQC-ALE Packed AMD message.) 


The two dictionaries sets provide a means to identify the most frequently used words 
communication for a mission. Dictionary Set 1 shall be the initial dictionary used for values 96 
through 127. When a character with value 1 is received in a Packed AMD Message, then 
Dictionary Set 2 shall be the word list for character values 96 through 127 until the end of that 
message or receipt of a character with value 0 in that message, after which Dictionary Set 1 shall 
again be used, and so on. 


Size in Bits 5 16 
Content 


Binary Value 
Bit Numbers 6 18 19 20 21 22 23 24 


Size in Bits 
Content 


Binary Value 
Bit Numbers IF 18 19 20 21 22 23 24 


Size in Bits 


Content 


Binary Value 111 
Bit Numbers 123 4 5 18 19 20 21 22 23 24 


FIGURE A-60. AQC-ALE dictionary lookup message. 


A network manager might choose to minimize air time and provide some unique information 
using Dictionary Set 1 by placing tactical user phrases in the dictionary, such as "AT WAY 
POINT". To identify where the a unit is, the AMD message "AT WAY POINT 1" would be 
entered. What would be transmitted in the Packed AMD message would be a 4 TRW Inlink 
event transmission consisting of INLINK, PART2, COMMAND, REPEAT preambles. That is 
the entire message would fit in one COMMAND TRW as: 


1. Message Type = AQC-ALE Packed AMD Message 


2. Look-up 1 = Index into Dictionary Set 1 for "AT WAY POINT" 
3. Look-up 2 = The character "1" 
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No spaces are needed because the lookup table transform shall place spaces into the expanded 
message as defined in table A-IL. 


TABLE A-XLVIII. Lookup tables for packed AMD messages. 


ASCII [Dictionary Set ASCII 64 ASCII 64 Dictionary Dictionary 
Ordinal |0 Character Set Character Set Set 1 Set 2 
Value (0 to 31) (32 to 63) (64 to 95) (96 to 127) (96 to 127) 


eco Ce 
pt |Gse set) [| A) Programmable | Programmable | 
a 
3 aN Prgrammabte [Programmable | 
4 fand_ | 8 (|) Prgrammabie [Programmable | 
ps fare) Prgrammabte [Programmable | 
peas rogammatie | roma 
0 
9 feach—_ |) Prgrammabte [Programmable — | 
P10 feast Proganmatie | regret 
i Jror [| Prgrammabte [Programmable — | 
p80 re rg 

i 

ifs J 
- snort [| Prgrammabte [Programmable — | 
ie JNor_ | 0 | P| Programmable [Programmable | 
for tf Prgrammabte [Programmable | 
is fon | 2 | | Programmable [Programmable | 
peor [3S Prgrammabte [Programmable | 
20 fae (|) Prgrammabte [Programmable — | 
pai fsours [| Programmabie | Programmable | 
-—22_fsystem [| _@ | _V___| Programmable | Programmable | 
p23 fiat | |W Prgrammabte [Programmable | 
p24 fried XY Prgrammabie [Programmable | 
(25 rais [9 YP Prgrammabte [Programmable — | 

26 
p27 fuse |) Prgrammabte [Programmable | 
-—28_west |= | 1 | Programmabie [Programmable | 
p29 wit [=| Prgrammabte [Programmable — | 
[30 prr Prarie | Prorat 
—at_jvou [| Prgrammabte [Programmable — | 


il 
esl 


it 


cael 
fre 
rac 


ee |i 


(etl 


> 
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TABLE A-IL. Adding spaces during AMD unpacking. 


Message Value is in a Message Value is in Message is Value is 
Dictionary ASCII-64 and not Alphanumeric 
Alphanumeric 


First Character of Message No Leading Space No Leading Space No Leading Space 


Last Expanded Character Add Leading Space No Leading Space Add Leading Space 
from Lookup 


Last Expanded Character is | Add Leading Space No Leading Space No Leading Space 
ASCH-64 


A.5.8.3.2.2 Channel definition (NT). 


The channel definition provides a system to reprogram the radio with a different frequency or to 
cause stations in a link to move to a traffic channel. This allows the radios to listen for general 
propagation characteristics in a common area and then move to a nearby channel to manage the 
inlink state transactions. By allowing a channel to be reprogrammed, the radio can adapt to a 
wide variety of conditions that may occur on a mission. If congestion is experienced on the 
assigned frequency, the stations shall return to the normal scan list and reestablish the call. 


The channel index number is specified from a range of 0 to 255. A radio shall have at least 100 
channels available for reprogramming. A channel index of 0 shall indicate that the receive and 
transmit frequencies are to be used for the remainder of this link. Other channel index numbers 
indicate that the new assignment shall be entered into the channel table. 


Size in Bits 3 


Content CMD | Channel Number 0 - 255 Emission Mode Spare 


Binary Value 110 
Bit Numbers 


Size in Bits 


Content 


Binary Value 
Bit Numbers 


Size in Bits 


Content 


Binary Value 
Bit Numbers 


FIGURE A-61. Channel definition and meet-me function. 


Frequencies shall be specified as a 21-bit values with each step being 100 Hz. See figure A-61 
for an example format of this message. A 2-bit value 0 for emission mode shall indicate upper 
side band and a value of 1 shall indicate a value of lower side band. Bits 17-18 refer to the 
receive frequency, bits 19-20 to the transmit frequency. 
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A.5.8.3.2.3 Slot assignment (NT). 


The slot assignment feature allows a control station to dynamically assign response slots for 
stations with which it is linked. In this manner, when a response is required from several stations 
in an inlink state, orderly responses can be generated. The slot width shall be in Tw. When set 
to 11 or less, the radio shall respond with the shortest form possible allowing for 5 Tw as timing 
error. Figure A-62 depicts the format of a slot assignment. 


[Size in Bits 
Content ie Slot Number Number of TWs in Slot 


Binary Value ee 


_Bit Numbers 12 3 4 a 20 21 22 23 24 


FIGURE A-62. AQC-ALE slot assignment. 


Examples of this usage would be setting up a link to several stations and then periodically polling 
them with an operator ACK/NAK request or a position report request. Each radio would respond 
at a specified time following that transmission. This form of time division multiplexing is self- 
synchronizing to minimize the need for time of day clock synchronization. If more traffic is 
required on a channel, slot widths can be expanded. 


A.5.8.3.2.4 List content of database (NT). 
The list content of database (FIGURE a-63) shall display the programmable values of a scanning 


radio such that the receiver can inter-operate with that station in the best possible manner. This 
command requests the contents to be displayed. The Database identifier shall be the ASCII36 
character set plus the characters “*” and “_”. 


Size in Bits 3 5 16 


CMD | Msald Packed ALE Address Indicating Database Identification. 
ee sg This may include the "*" and "_" Characters 
Binary Value 110 x x x x x 


| 
Bit Numbers 123 4 5 6 7 11.12 #13 #14 #15 16 #17 #18 «19 20 21 22 23 24 


FIGURE A-63. List content of database. 


A.5.8.3.2.5 List database activation time (NT). 


This function requests the time stamp of a database. Its format is identical to that shown in 
figure A-64. 


A.5.8.3.2.6 Set database activation time (NT). 

This function (figure A-64) sets or displays the time stamp of a database. The first word format 
of the command is identical to the List Content of Database. The second word contains the time 
of day that the database is to be active. Only one database shall be active at a time. When the 
SET bit=1, the command represents the time to assert when the database becomes active. When 
the SET bit=0, this is a report of the current time set value. 


213 


MIL-STD-188-141B 
APPENDIX A 


A network control station can program or select preprogrammed channel sets and then cause all 
mission participants to switch to a new set of channels to operate upon. Other uses would 
include moving from one area of the world to another may cause the user to move into a different 
set of allocated frequencies. 


[Size in Bits 16 
Packed ALE Address Indicating Database Identification. 
This may include the "*" and "_" Characters 


Content 


Binary Value 
Bit Numbers 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 


Size in Bits 21 


Content Data Activation Day sein 5 Activation Hour Activation Minute 
ee ee ee eee 


Binary Value 
Bit Numbers 10 11 12 13 14 15 16 17 #18 19 20 21 22 23 24 


FIGURE A-64. Set database activation time. 


A.5.8.3.2.7 Define database content (NT). 

This function defines a database over the air. The first TRW format of the command is identical 
to the List Content of Database. Subsequent words contain association of existing information 
into a dataset that the radio may operate against. As shown in figure A-65. 


Size in Bits 
Packed ALE Address Indicating Database Identification. 


content This may include the "*" and "_" Characters 


Binary Value 
Bit Numbers 


Size in Bits 
Content 


Binary Value 
Bit Numbers 123 4 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 


Size in Bits 3 21 


Content Repeat] Spare Channel Number 1 Channel Number 2 


Binary Value 


Bit Numbers 12:3). A 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 


Size in Bits 3 21 


Content } bate | spare Channel Number 3 Channel Number n+3 
| 00 0 | 


Binary Value 
Bit Numbers 1 9 10 11 12 13 14 15 16 17 #18 19 20 21 22 23 24 


FIGURE A-65. Define database content. 
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Word 2 of the message shall consists of: 


1. 
2: 


3 


3 bits of LP Level number. Values range from 0 through 4. 

1 bit for Lower Level Linking. When set to 1, the radio shall honor lower level link 
attempts. 

3 bits for LP Key number identification. A value of 0 indicates no key assignment. 
When an LP level greater than 0 exists, this would be an non-operational condition. If 
more than one type of key is used between LP levels, they must use the same key index. 
When a radio does not have a key present for a given LP Key, a value of NOKEY shall 
be used. 

5 bits for the number of channels. Immediately following this word shall be 
(number_of Channels/2) words containing the channel numbers to use. Earlier 
commands defining channel numbers or a preprogrammed value define the actual 
frequencies used. 


. 6 bits for defining the words from a dictionary into the 64 words. The mapping of a 


dictionary into a database dictionary allows a specific set of words that yield a higher 
frequency hit rate to the dictionary. A value of 0 indicates using the orginal programmed 
dictionary. The mapping of the dictionary is contained in the Trw that follow the 
channel association. 


A.5.8.3.2.8 Database content listing (NT) 
This command shall have the same format as the Define Database Content. 


A.5.8.4 AQC-ALE linking protection (NT). 

When operating in LP with AQC-ALE, every 24-bit AQC-ALE word shall be scrambled in 
accordance with Appendix B. The same rules for LP in baseline 2G ALE shall be applied to 
AQC-ALE with the following exceptions: 


The word number for all TO AQC-ALE words during the scanning call shall be 0, 
and the word number for all PART 2 AQC-ALE words during the scanning call shall 
be 1. The TIS or TWAS word that concludes a scanning call shall use word number 2 
and the following PART 2 word shall use word number 3. 


The AQC-ALE response frame shall use word numbers 0, 1, 2, and 3. 


A 2-word AQC-ALE acknowledgement shall use word numbers 0 and 1. The TOD 
shall be later than that used at the end of the scanning call. 
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ANNEX A. DEFINITIONS OF TIMING SYMBOLS 


Number of channels in sequence 


Handshake. Completed sequence of call, response, and 
acknowledgment 
Integer 


Number of addresses 

Number of addresses with “m” words 
Number of original individual address words 
Number of slots in response period, total 
Seconds 

Slot number identification 

Time 

Individual station (or net) whole address time 


Individual station (or net) address first word time 


Maximum individual station (or net) whole address time limit 


Call time, combination of whole address(es), which is usually repeated 


as a leading call Tj. 
Combined different first words of group station address 


Calling cycle time 


Maximum call time limit 


Basic dwell time on each channel during scan. Sometimes shown with 


channels per second scanning rate in ( ) e.g. Ta (5). 
DBM time 


Decode time 

Detect rotating redundant word time 
Detect redundant word time 

Detect signaling (tones and timing) time 


Encode time 
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Leading call time 

Late detect word additional time 

on-air leading redundant words 

Last word wait delay 

Orderwire message section time 

Maximum orderwire message section time limit 
Propagation time 

Periodic sounding interval 

Redundant call time 

Receiver internal signal delay time 

Redundant sound time 

scanning redundant call time 

Redundant word time (392 ms) 

Redundant word phase delay (0 to T,w) 

Scan period 

Scan calling time, same as Tss 

Maximum scan period 

Minimum scan period 

Scanning redundant call time 

Scanning redundant sound time 

Scan sounding time, same as Ts 

Slot width time 

Slot wait time delay after end of call, until slotted response starts 
Tuneup time delay of antenna tuner or coupler 
Turnaround time, receipt of end of signal to start of reply 
Transmitter command (to transmit) time 
Transmitter internal signal delay time 
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Transmitter acknowledgment (that is transmitting) time 
Tone (8 ms) 

Word time (130.66...ms) 

Wait for activity time 

Wait for net acknowledgment time (for called stations) 


Maximum limit group call wait for reply time (for late arrival called 
stations) 
Wait for calling cycle end (message or terminator stations) 


Wait for reply time 

Wait for net/group reply time (for calling stations) 
Wait for reply and tune (scanning) time 

Wait (listen first) time before tune or transmit 
Termination section time 

Maximum termination section time limit 

Wait for reply timer (load with Ty,) 


Wait for response and tune timer (load with Tyen or Twrt) 
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ANNEX B. TIMING 


NOTE: Refer to annex A and table A-XV. 
Basic system timing 


e Tone (symbol) rate = 125 symbols per second 


e Tone period: 
Ttone = 8 ms per symbol 


e On-air bit-rate = 375 bits per second 


e On-air individual word period (never sent alone): 
Ty = 16.33... symbols x Ttone = 130.66...ms 
e On-air (triple) redundant word period: 
Tw = 3Ty = 49 tone = 392 ms 
e On-air individual (or net) address time for m = | to 5 words: 
Ta = MX Ty = 392 ms to 1960 ms 
e Propagation time, range divided by speed of wave, for MF/HF signals, local to global: 
Tp = 0 to 70 ms 


System timing limits 


e Maximum individual station (or net address time limit), based on 15-character (or 5- 
word) maximum: 


Ta max = 5 Tr = 1,960 ms 
e Individual (or net) address first word, used in scan call Tse: 
Ta = Tr = 392 ms 


e Maximum group combined addresses different first words time limit, maximum 5 first 
words, in scan call Ts: 


Toa = X= Ta (different) 
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Tcl max = 5 Tal = 5 Trw = 1960 ms 
e Maximum call time limit, based on 12-word maximum, chole addresses in T\:: 
Tc max = 12 Trw = 4,704 ms 
e Maximum scan cycle period limit, based on 2 channels per second and 100 channels: 
Ts max = 50s 
e Maximum message (orderwire) section time limit, unless adjusted by CMD: 
Tm max basic = 30 Trw = 11.768 
Tm max including Tm max AMD = 29 Trw* + 30 Trw = 23.128 s 


Tm max including Tm max DTM = 29 Trw* + 353 Trw = 382 Trw 
(149.744s) 


Tm max including Tm max DBM = 29 Trw* + 3560 Trw = 3589 
Trw (1406.888s) 


*NOTE: Tin max basic equals 29 Ty when combined with AMD, DTM, or DBM. This is due 
to the requirement to commence the AMD, DTM, or DBM transmission one T, (392) ms) 
prior to the close of Tm max basic which effectively reduces the value of Tm max basic to 29 


Trw in these equations. 


e Maximum termination section time limit, same as Ta max: 


= Ta max = 1,960ms 


Ey max 


Individual calling 


e Initial and minimum dwell time on each channel by receiving station during normal 
receive scanning; inverse of scanning rate; not including extended pause to read word: 


Ta(5)min = 200 ms at 5 channels per second basic scan rate, or 
Ta(2)min = 500 ms at 2 channels per second minimum scan rate 


Ta(10) min = 100 ms at 10 channels per second (DO) 
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e Scan period for receiving station to scan all scanned channels during normal receive 
scanning, where “C” is the number of scanned channels; not including extended pause to 
read words: 


Ts min — Cx Ta min 


For example, 
Ts min = O for single-channel, nonscan case, or 
= 2 seconds for typical C = 10 at 5 chps, or 


= 5 seconds for C = 102 chps minimum rate 


II 
II 


1 seconds for C = 10 at chps (DO) 


e For scan call Ts; computations, use T; based on probable maximum pause on each 
channel (Tg, to read words) of Tay = 2 Tr (Ta may be adjusted by net managers for best 
system performance): 


T,; = CxTg = CX Taw 


For example, 
T; = 7,840 ms for C = 10 channels and Tg = Taw 


e Call time, the called whole address (or combination of called whole addresses, if a group 
call), which may be repeated in the leading call T1,; maximum limit 12 one-word 
addresses: 


T. = T, (called) for single-station (or net) calls, or 
= T, (first) + T, (second) + T, (last) if group call 


e First-word call time, the called address first word (or combination of addresses first 
words, if a group call), which is repeated in the scanning call T,,.; maximum limit 5 
different first words: 


Tic = Tai (called) for single-station (or net) calls, or 
= T, (first) + Ta: (second different) + T,, (last different) if group call 


e Leading call time, composed of two complete repetitions of Tc, which contains the whole 
address(es): 


221 


MIL-STD-188-141B 
APPENDIX A 
ANNEX B 


Tic = 2T, = 2T, (called) for single-station (or net) calls, or 
= 2(T, (first) + T, (second) + T, (last), if group call 


e Scanning call time, consisting of repetitions of only the first word(s) Ta; of the called 
address (or combination of addresses, if a group call), for calling station to “capture” 
scanning receivers during normal scanning calling. Therefore, Ts. is a multiple T.; (group 
of T,1’s if a group call) of words, which is > the receiver’s scan period T;, where n is any 
integer such that Ts, = Ts: 


Ts) = 0X Ty 2 Ts = Cx Ta 


For example, 


Tsc = 0 for single-channel individual call case, or 


>20 Tw = 7840 msifC = 10 and Tg = Taw 


e Calling cycle time for calling station to both “capture” scanning receivers and ensure 
reading the called station address(es), consisting of scan calling time (Ts-) plus leading 
call time (T1,), respectively: 


Tee = Tse a0 Tic2 Ts + Tic 


For example, 


Too = Tic = 2T, (called) = 784 ms for single-channel one-word address 
individual (or net) call case (T; = 0), or 


= Ty + Tic = (20 + 2) Tr + 8624 msifC = 10 andTg = Taw 


e Single-channel redundant call time, consisting of individual (or net) leading call T;, (with 
TO) plus terminator T, (with TIS or TWAS), not including any message section time: 


Tro = Tic + Tx =2T, + Tx = 2T, (called) + T, (caller) 
= 3 Tw min = 1176 ms minimum, for individual station 
(or net) call using one-word addresses. 
= 15 Tw min = 5880 ms max for 5-word addresses 


e Scanning redundant call time, consisting of scanning call time Ts, and redundant call 
time Ty, respectively: 
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Tse a T sc tr Tre 


For example, using one-word addresses: 
Tere = (20 + 3) Tw = 9016 msifC = 10 and Tg = Taw 


e Last word wait additional fixed delay at replying or receiving station, after (possibly 
early) detected end of received call and before start of reply, to avoid on-air overlap, loss 
of additional termination (caller address) words, and to allow for transmitter turnaround 
for reception: 


Tiwy = Tw = 392 ms 


e Late word detection additional fixed delay at calling station, to increase wait for reply 
time in case of possibly late detection at called station: 


Tiq = Tw = 130.66...ms 


e Redundant word phase delay. To synchronize a transmission to any recently preceding 
transmissions, and used on all but first transmission of a handshake or exchange until 
terminated period: 


Trwp = 0 to 392 ms < Try 


e Turnaround time at replying station, measured at rf port(s); from end of received signal to 
start of transmitted reply, not including delays such as T1 ww internal signal delays, Tya 
and Tig; decode and encode times, Tyex and Tenk; and transmitter command and 
acknowledgment delays, Ti. and Tix: 


Tra = Tra Taek Tenk Tte Tk Tta 


For example, approximations: 


Tia = 0 for new, fast equipment, or 
= 2Ty = 261.33...ms estimated allowance for old slower equipment 


e Wait for calling cycle end time at receiving station, is delineated by receipt of start of 
message, terminator, or quick-ID section: 


Twee = 2 x Ts (of own station) as default value 


e Wait for reply time at calling station, from end of transmitter signal to start of received 
reply detection periods (Tas, Taw, and Tanw, below); including propagation, T,; last word 
wait, Tiyww; late word detection, T,4; turnaround, Ti; redundant word phase delay (if not 
first transmission in handshake or exchange), Trwp;, and receiver and transmitter internal 
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signal delays, Ta and Tig; in a single-channel case without tune times, or multi-channel 
scanning case after first tune and transmission: 


Twr = Tia + Tp + Tiww + Tiww + Tia + Trvp (Gif not first) + Tia + Tp 
+ Tr4 


For example, approximations: 


Tw = 5Ty = 653.33... ms for fast equipment, or 


=7Ty = 914.66... ms for slower equipment, maximum 


=8Ty = 1045.33..ms for fast equipment if not first 


=10T, = 1306.66..ms for slower equipment if not first 


e Tune time delay, after issuance of tune-up command and before ready to transmit the 
reply signal: 


T; = maximum tune-up delay for slowest tuner in system (or net/group 
being called) 


For example, typical allowance ranges are: 


T;> Tw = 130.66... ms for fast (solid state) tuners or 
>8T, = 1,045.33... ms for fast relay tuners, or 


> 20 seconds for old electromechanical (servo drive) tuners, or as required 
by available equipment 


NOTE: If tune time(s) of called station(s) is unknown, first try default value shall be 8 T,, and 
second try default value shall be at least 20 seconds. 


e Wait for response and tune time, same as wait for reply Tyr, plus tune time T; in scanning 
cases, and relevant only to first transmission on a channel (which requires tuning time): 


Twe = Tw + Th 


For example, typical allowance ranges are: 


Twt = 6 Ty = 784 ms for fast tuners, or 
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15 T, = 1,960 ms for slower tuners, or adjusted as required by available 
equipment 


NOTE: If tune time(s) of called station(s) is unknown, first try default value shall be 15 Ty 
and second try default value shall be at least 20 seconds. 


e Detect signaling tones and timing (of call or reply) detection period; after arrival on 
channel during normal receive scanning, or after end of wait for reply time Ty; or Twrt 
during normal calling, and before automatic return to normal receive scanning; used to 
identify channel vacancy or occupancy with standard ALE signaling. 


Tas < Ta(5) = 200 ms 


e Detect redundant words detection period, starting same as Tags, and used to continue 
beyond Tg; if tones and timing are detected, before automatic return to normal receive 
scanning; used for acceptance of basic single-word (and address first work) addressing 
and to real calls: 


Taw = Tr + spare Tw = 6 Ty = 784...ms 


e Detect rotating redundant words detection period, starting same time as Tys, and used to 
continue beyond Tarw if redundant words are detected, before automatic return to normal 
receive scanning; used for acceptance of extended (multiword) addressing and/or group 
calls: 


Tarw = 2 Try + spare Try = 9 Ty = 1,176 ms 


Sounding 


e Single-channel redundant sound time, like leading call T;,, but with only the “TIS” or 
“TWAS” terminator, using twice the whole address: 


Tis = 2T, (caller) 


For example, 


Tis = 2Trw = 784 ms minimum, individual single-word address sound on 
a single channel 
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e Scanning sound time. Like Ts, but using whole address only (not just first word of 
address): 


Tsys = nx T, (caller) => Ts 


e Scanning redundant sound time, like calling cycle time, T., consisting of redundant 
sound time T,;, with addition of scanning sounding time T;; (which is identical to Ts): 


Ts = Tss + Trs = @ oc n)T, (caller) => T; + Tis 


For example, 


Tsrs = (20 +2) Tw = 8,624 ms if C= 10, and Ta = Taw 


Star calling 


e Minimum uniform slot width for automatic slotted responses in normal single-word 
address star net and group calling protocols (but may be modified by CMD): 


Tsw (min) = 14 Ty = 1,829.33... ms for standard replies, or 
=17Ty = 2221.33...ms for LQA replies, or 
= 9 Ty = 1,176 ms for only fixed “tight slot” replies, or 


=nx Ty by CMD 


NOTE: Replies above are for first transmissions; if not, Tsy min = 17,20, and 12 Ty 
respectively, (due to redundant word-phase delay). 


e Slot wait time before start of slotted response and after detection of end of calling signal, 
where SN is the assigned (or derived) slot number, for group or preset net calling: 


Tsw(SN) = Tsw x SN for uniform slot widths 
(by CMD or net manager), or if non-uniform (customized) slot width 


Tswi(SN) = SN [5 Ty + 2T, (caller) + (optional LQA) Ty, (optional 
message) Tm] + Ta (caller) + [(sum of all previous w, called addresses) ] 


m = SN-1 


= T,(m)(called) 
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m= 1 


as the general case. 


For example, 


Tsw(5) = 14 Ty x 5 = 70 Ty = 9,146.66...ms delay for start of normal 
5th slot response, first time, no LQA, single word address. 


e Wait for net reply buffer time at calling station, after end of star net or group call, until 
responses should be received and an acknowledgment can be started, where “NS” is the 
total number of slots (including slot 0): 


Twm (calling) = (Tsw x Ns) for uniform slots or generally, Ts: (NS) 


e Wait for net acknowledge buffer time at called stations, to receive acknowledgment after 
end of star net or group call: 


Twan(called) = (Tsy x NS) + Taw 
=Tyn(calling) + 2Tyy 


e Turnaround plus tune time totals for slotted responses have the following limits (not 
including Tiww): 


Tat 1, 1500 ms for standard slots, except 
2100 ms for slot 1 only, or 
360 ms for slot 0 emergency or interrupt 
e Maximum star group wait for acknowledgment time at called stations: 
sl wan max: = 107 T,, + 27 T, (caller) + 13 Try (optional LQA) + 
13 Tn(optional message) 


e Default maximum star group wait for acknowledgment time for late arrival, called 
stations, not knowing the size of the group. There are two default maximum waiting 
values, before automatically returning to normal receive scanning, if no message and 
caller uses single-word address: 


Teanciax = 188 Ty = 24,563.33...ms if standard or, 


Pay i GAs 


29,661.33...ms if LQA requested 
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Programmable timing parameters 


Unless otherwise programmed by the network manager, the following typical timing values are 
recommended: 
e Dwell time per channel, basic receive scanning: 


Ta(5) = 200 ms for 5 chps basic scan rate 
e Dwell time per channel, minimum receive scanning: 
Ta(2) = 500 ms for 2 chps minimum scan rate 


e Dwell time for calculations of T; (and Tc), based on probable maximum typical pause 
(may be adjusted by net manager for best system performance): 


Ta = Tarw = 2Tiw = 784 ms 


Wait (listen first) time before tune or transmit: 


Tw | = 2 seconds for voice or general purpose channels or, 


= Taw = 784 ms for ALE and data only channels 


Tune time allowance for wait for response time is normally set for slowest known tuner in 
associated network; except if unknown parameter (such as in blind internet calls to “strangers”): 


T; = 8Ty = 1045.33...ms for first call, and 


20 seconds for next try 
e Automatic periodic sounding intervals (when channels are clear): 


Tps = 45 minutes when enabled (T,; must be capable of being disabled). 


Wait for activity time after linking or use, before automatic return to normal receive scanning: 


Twa = 30 seconds when enabled (Twa must be capable of being disabled). 
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ANNEX C. SUMMARY OF ALE SIGNAL PARAMETERS 


ALE occupied bandwidth 


Quantity of tones 
Tone frequencies 
Tone values 
Symbol changes 
Symbol structure 
Symbol rate; period 
Uncoded data rate 


Forward error correction 


Auxiliary coding (DTM, 


Auxiliary coding (DBM) 


Coded data rate (DTM, AMD, basic 
ALE) 


Coded data rate (DBM) 


Coded data bits per basic ALE word 
(DTM, AMD) 


Coded data bits per message (DTM) 


Coded data bits per message 
Throughput, maximum data rate 
(DTM, AMD, basic ALE) 


Throughput maximum data rate 
(DBM) 


500-2750 Hz 

8 (one per symbol period) 

750; 1000; 1250; 1500; 1750; 2000; 2250; 2500 Hz 
000 001 011 010 110 111 101 100 

Tone transitions are phase continuous 

3 bits of binary coded data 

125 symbols per second (sps); 8 ms 

375 bits per second (b/s) transmitted 


Golay (24, 12, 3) half-rate coding (4 modes of (FEC) 
correct/delect; 3/4, 2/5, 1/6, or 0/7) 


Redundant x 3, with 2/3 majority vote (with 49 AMD, 
basic ALE) transmitted bits) 


Interleaving depth (ID) = 49 to 21805 = (n x 49) 
61.22 b/s 


187.5 b/s 

24 (21 (3 characters) plus 3 preamble), per word 
From 0 to 7371 bits per block 

From 0 to 261644 bits per block, plus 16 bits CRC 
(DBM) 


53.57 b/s data bits 


187.5 b/s data bits 
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Characters per word (AMD or basic 0 to 3 expanded 64 or full ASCII 
ALE) 


Character per message (DTM) 0 to 1053 ASCII characters per block 
Character per message (DBM) 0 to 37377 full ASCII characters per block 
Character rate (DTM, AMD, basic 7.653 cps 

ALE) 

Character rate (DBM) 26.79 cps 


Equivalent throughput maximum word 76.53 words per minute (wpm) (5 character plus space 
rate (DTM, AMD) per word) 


Equivalent throughput maximum word 267.9 wpm (5 character + space per word) 
rate (DBM) 


Unit period (DTM, AMD, or ALE 130.66 ... ms per word (T,) or 392 ms per triple 
word) redundant word (T,w) 

Message period (DTM) 0 to 2.29 minutes per block 

Message period (DBM) 0 to 23.26 minutes per block 

Minimum sound time 784 ms (2 Try) 

Minimum call time 1176 ms (3 Tyw) 

Minimum handshake time 3528 ms (9 T,w) three-way linking 

Preamble (word types) 8 (3 bits) 

Character sets or random bits ASCII (Basic 38, expanded 64, full 128), 

Link quality analysis (LQA) ALE (BER, SINAD, and MP) 
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LINKING PROTECTION 
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APPENDIX B 
LINKING PROTECTION 
B.1 GENERAL. 
B.1.1 Scope. 


This appendix contains the requirements for the prescribed protocols and directions for the 
implementation and use of high frequency (HF) automatic link establishment (ALE) radio linking 
protection. 


B.1.2 Applicability. 
This appendix is a mandatory part of MIL-STD-188-141 whenever linking protection (LP) is a 


requirement for the HF radio implementation. The functional capability herein described 
includes linking protection, linking protection application levels, and timing protocols. The 
capability for manual operation of the radio in order to conduct communications with existing, 
older generation, non-automated radios shall not be impaired by implementation of these 
automated procedures. 


B.2, APPLICABLE DOCUMENTS. 


B.2.1 General. 

The documents listed in this section are specified in B. 3, B. 4, and B. 5 of this standard. This 
section does not include documents cited in other sections of this standard or recommended for 
additional information or as examples. While every effort has been made to ensure the 
completeness of this list, document users are cautioned that they must meet all specified 
requirements documents cited in B. 3, B. 4, and B. 5 of this standard, whether or not they are 
listed. 


B.2.2 Government documents. 


B.2.2.1 Specifications, standards, and handbooks. 

The following specifications, standards, and handbooks form a part of this document to the 
extent specified herein. Unless otherwise specified, the issues of these documents are those 
listed in the issue of the Department of Defense Index of Specifications and Standards (DODISS) 
and supplement thereto. 


STANDARDS 
FEDERAL 


FED-STD-1037 Telecommunications. Glossary of 
Telecommunication Terms 


(Unless otherwise indicated, copies of federal and military specifications, standards, and 


handbooks are available from the Standardization Document Order Desk, 700 Robbins Avenue, 
Building #4, Section D, Philadelphia, PA 19111-5094.) 
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B.2.2.2 Other Government documents, drawings, and publications. 
The following other Government documents, drawings, and publications form a part of this 
document to the extent specified herein. Unless otherwise specified, the issues are those cited in 
the solicitation. 

None. 


B.3 DEFINITIONS. 


B.3.1 Standard abbreviations and acronyms. 
The abbreviations and acronyms used in this document are defined below. Those listed in the 


current edition of FED-STD-1037 have been included for the convenience of the reader. 


2G second generation 

3G third generation 

2G ALE second generation automatic link establishment 
3G ALE third generation automatic link establishment 
AL-0 unprotected application level 

AL-1 unclassified application level 

AL-2 unclassified enhanced application level 

AL-3 unclassified but sensitive application level 
AL-4 classified application level 

ALE automatic link establishment 

AMD automatic message display 

ASCII American Standard Code for Information Interchange 
BWI Burst Waveform 1 

CMD ALE preamble word COMMAND 

CRC cyclic redundancy check 

DBM data block message 

DO design objective 

DODISS Department of Defense Index of Specifications and Standards 
DTM data text message 

FEC forward error correction 

HF high frequency 

ICD interface control document 

LP linking protection 

LPCM linking protection control module 

ms millisecond 

NSA National Security Agency 

NT Not Tested 

PDU protocol data unit 

PI protection interval 

REP Repeat preamble in 2G ALE 

TOD time of day 
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B.3.2 Definitions of timing signals. 
The abbreviations and acronyms used for timing symbols are contained in Annex A to Appendix 
A. 


B.4 GENERAL REQUIREMENTS. 


B.4.1 LP overview. 

The LP procedures specified herein shall be implemented as distinct functional entities for 
control functions and bit randomization functions. (Unless otherwise indicated, distinct 
hardware for each function is not required.) Figure B-1 shows a conceptual model of the 
MIL-STD-188-141 data link layer functions, showing the placement within the data link layer at 
which LP shall be implemented. The linking protection control module (LPCM) shall perform 
all control functions specified herein and interface to the ALE controller as shown on figure B-2. 
Scrambler(s) shall perform all cryptographic operations on ALE words, under the control of the 
LPCM. Use of LP shall neither increase the time to establish a link compared to the non- 
protected radio, nor degrade the probability of linking below the standard set for non-protected 
linking in Appendix A, table A-II. A means shall be provided to disable the LP functions and 
operate the radio in the clear unprotected application level (AL-0). Hardware scramblers shall be 
removable without impairment of the unprotected application level functionality of a radio. 
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SEVEN LAYER 


APPLICATION 
LAYER 


PRESENTATION 
LAYER 


SESSION 
LAYER 


TRANSPORT 
LAYER 


NETWORK 
LAYER 


DATALINK 
LAYER 


PHYSICAL 
LAYER 


FIGURE B-1. Data link layer with linking protection sublayer. 
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CONTROLLER 


PROT. ALE FEC 
CONTROL MODULE 
MODULE 


TRAFFIC 
MODULE 


FIGURE B-2. Data flow in a protected radio. 


B.4.1.1 Linking protection application levels. 
The application levels of LP are defined herein. The classified application level (AL-4), which 


offers the highest degree of protection, and the unclassified but sensitive application level (AL-3) 
use National Security Agency (NSA) controlled algorithms described in classified documents. 
This standard can only make reference to these documents with very little other descriptive 
material. All protected radios shall be capable of operation at the unclassified application level 
(AL-1). A means shall be provided to disable automatic linking at linking protection application 
levels less secure than the application level in use by the station being called. For example, a 
station which is operating at unclassified enhanced application level (AL-2) shall be able to 
disable the receiver from listening for linking attempts at unprotected application level (AL-0) 
and AL-1. (Design objective (DO): Alert the operator but do not link automatically when a valid 
call is received from a transmitter with a lower linking protection application level.) This 
mechanism shall not preclude the operator from manually initiating ALE using a disabled 
application level. This manual override is required for interoperability. 


B.4.1.1.1 AL-0. 

Assignment of the AL-0 indicates that no linking protection is being employed. No protection is 
provided against interfering, unintentional, or malicious linking attempts. All protected HF 
radios shall be capable of operation in the AL-0 mode. 
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B.4.1.1.2 AL-1. 

The AL-1 unclassified application level is mandatory for all protected radio systems, and 
therefore, provides protected interoperability within the U.S. Government. All protected radios 
shall be capable of operation in the AL-1 mode even if they also provide application levels with 
greater protection. The AL-1 scrambler shall employ the lattice encryption algorithm as specified 
in B.5.6, and may be implemented in hardware or software with manufacturer-specified 
interfaces. This scrambler is for general U.S. Government and commercial use. The AL-1 
protection interval (PI) is 60 seconds, which provides slightly lower protection than any of the 
other available protected modes but allows for relaxed synchronization requirements. 


B.4.1.1.3, AL-2. 

The AL-2 scrambler shall employ the same algorithm as specified for the AL-1, and may be 
implemented in hardware or software, with manufacturer-specific interfaces. This scrambler is 
for general U.S. Government and commercial use. The AL-2 PI is 2 seconds. 


B.4.1.1.4 AL-3. 

AL-3 shall use distinct hardware scramblers and shall employ an algorithm and the 
corresponding interface control document (ICD) developed by the NSA. Systems employing the 
AL-3 LP shall meet NSA security requirements. The AL-3 PI is a maximum of 2 seconds. 


B.4.1.1.5 Classified application level AL-4. 

AL-4 shall use distinct hardware scramblers and shall employ an algorithm and the 
corresponding ICD developed by NSA. An AL-4 scrambler may be used to protect classified 
orderwire traffic. Systems employing classified application level LP shall meet NSA security 
requirements. The AL-4 PI is a maximum of | second. 


B.4.2 Protocol transparency. 

A principal consideration in implementing LP is that the presence of an LP module in a radio (or 
its controller) shall have no impact on any protocols outside of the protection sublayer in the 
datalink layer. In particular, this means that achieving and maintaining crypto sync shall occur 
transparently to the ALE waveform and protocols, and that scanning radios shall be able to 
acquire cypto sync at any point in the scanning call portion of a protected transmission if this 
transmission was encrypted under the key in use by the receiving station. Thus, LP modules 
shall not insert sync bits into the data stream, and shall acquire crypto sync without the use of 
synchronization preambles or message indicator bits. 


B.4.3 Transmit processing. 

The LP module in a sending station shall encrypt each 24-bit ALE word to be sent using the seed 
data then in use (frequency, PI number, word number, etc. See B.5.2.3.) and delivers the 
encrypted word to the FEC module. (Data Block Mode is a special case. See B. 5. 3. 4.) 


B.4.4 Receive Processing. 

The receiver side of an LP module is responsible for achieving crypto sync with transmitting 
stations, and for decrypting protected ALE words produced by Golay decoder. In operation, 
when a scanning receiver arrives at a channel carrying valid tones and timing, the FEC sublayer 
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(majority voter, de-interleaver, and Golay decoder) shall process the output of the ALE modem 
and alert the LP receive module when an acceptable candidate word has been received. (This 
occurs roughly once every 8 milliseconds (ms) when the Golay decoders are correcting three 
errors, or once every 78 ms when correcting one error per Golay word.) 


The receive LP module shall then decipher the candidate word, and pass it to the receiving ALE 
module, which will determine whether word sync has been achieved by checking for acceptable 
preamble and ASCII subset. This task is complicated by the possibility that the received word 
(even if properly aligned) may have been encrypted using a different PI than that at the receiver, 
requiring the receiving LP module to decrypt each candidate word under several seeds. 


A further complication is the possibility, though small, that a word may satisfy the preamble and 
character set checks under multiple seeds. When this occurs, the valid successors to all seeds, 
which produced valid words, are used to decrypt the next word, and each result is evaluated in 
the context of the corresponding first word. The probability is vanishingly small that multiple PI 
possibilities will exist after this second word is checked. 


For example, if during a scanning call (or sound), a received word decrypts to “TO SAM” using 
seed A, and to “DATA SNV” using seed B, the next word is decrypted using the successors to 
those seeds, denoted A’ and B’. If the result of decrypting this next word under A’ is not “TO 
SAM,” the first decrypt under seed A was invalid because the word following a TO word ina 
scanning call must be the same TO word. To be valid in a scanning call or sound, a word 
following “DATA SNV” must have three ASCII-38 characters and a THRU, REPEAT, TIS or 
TWAS preamble. All valid preamble sequences may be found in Appendix A (table A-VIII). 


B.4.5 Time of day (TOD) synchronization. 

Because LP employs PIs (which are time-based), all stations must maintain accurate TOD clocks. 
Practical considerations suggest that station local times may differ by significant fractions of a 
minute unless some means is employed to maintain tighter synchronization. Because the 
effectiveness of LP increases as the length of the PI decreases, there is a trade-off between 
protection and the cost of implementing and using a time synchronization protocol. 


The approach taken here is to rely on operators to get station times synchronized to within | 
minute (plus or minus 30 seconds), and then to employ a protocol to synchronize stations to 
within | or 2 seconds (fine sync) for full linking protection. While it is possible to operate 
networks with only coarse (1 minute) time synchronization, this reduces the protection offered by 
this system against playback (tape recorder) attacks. 


Synchronization of local times for LP requires some cooperation between the protocol entity and 
the LP time base. For this reason, the LP module, which already has access to the time base for 
its normal operations, appears to be the logical entity to execute the synchronization protocols, 
although these protocols are logically at a higher layer in the protocol stack than the LP 
procedure. In this case, the LP module would need to examine the contents of received 
transmissions to extract relevant message sections. 
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If, instead, the synchronization protocols are executed by the ALE entity, the division of function 
by level of abstraction is cleaner. One concept of how the coordination across the ALE-LP 
sublayer boundary may be effected in this case is as follows: 


a. TOD is maintained by the ALE entity, and is provided to the LP entity as required. 


b. The transmit LP entity uses the TOD provided by the transmit ALE entity to form seeds 
during T,, and for the initial time setting for T;,. Thereafter, the TOD from ALE is ignored, 
and the transmit LP entity sequences seeds in accordance with the state diagram in figure 
B-4. 


c. On the receive side, seed sequencing is performed by the functions responsible for 
achieving and maintaining word sync. These functions may be implemented within either 
the LP or the ALE module, but must know the current phase of the ALE protocol (e.g., Tse, 
Tic, and so on). 


d. For authentication of clear mode time exchanges, the ALE module must be able to call 
upon the LP module to encrypt and decrypt individual ALE words “off line.” 


B.5 DETAILED REQUIREMENTS 


B.5.1 Linking protection. 
The following requirements apply to both second generation automatic link establishment (2G 
ALE) and third generation automatic link establishment (3G ALE) unless otherwise stated. 


B.5.2 LPCM. 
The LPCM shall execute the LP procedure specified in B.5.3 and control the attached 
scrambler(s) as specified below. 


B.5.2.1 Scrambler interfaces. 

The LPCM shall interact with the scrambler(s) in accordance with the circuits and protocols 
specified in the interface control document (ICD) for each scrambler (see B.4.1.1.4 and 
B.4.1.1.5). For AL-1, the ICD is prepared and controlled by the manufacturer. 


B.5.2.2 TOD. 
The LPCM requires accurate time and date for use in the LP procedure. The local time base shall 
not drift more than +1 second per day when the station is in operation. 


B.5.2.2.1 TOD entry. 

A means shall be provided for entry of TOD (date and time) via either an operator interface or an 
electronic fill port or time receiving port (DO: provide both operator interface and electronic 
port). This interface should also provide for the entry of the uncertainty of the time entered. If 
time uncertainty is not provided, a default time uncertainty shall be used. Defaults for the 
various time fill ports may be separately programmable. Default time uncertainty shall be 
determined by the procuring agency or manufacturer. Default uncertainty of + 15 seconds is 
suggested. 
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B.5.2.2.2 Time exchange protocols. 

After initialization of TOD, the LPCM shall execute the time protocols of B.5.5 as required, to 
maintain total time uncertainty less than the PI length of the most secure LP mode it is using. 
The LPCM shall respond to time requests in accordance with B.5.5.3 unless this function is 
disabled by the operator. 


B.5.2.3, Seed format. 

The LPCM shall maintain randomization information for use by the scrambler(s), and shall 
provide this information, or “seed,” to each scrambler in accordance with the applicable ICD. 
The 64-bit seed shall contain the frequency, the current PI number, the date, and a word number 
in the format shown on figure B-3, where the most significant bits of the seed and of each field 
are on the left. The TOD portion of the seed shall be monotonically non-decreasing. The 
remaining bits are not so constrained. The date field shall be formatted in accordance with figure 
B-3. The month field shall contain a 4-bit integer for the current month (1 for January through 
12 for December). The day field shall contain a 5-bit integer for the current day of the month (1 
through 31). A mechanism shall be provided to accommodate leap years. The PI field shall be 
formatted in accordance with figure B-3. The coarse time field shall contain an 11-bit integer 
which counts minutes since midnight (except that temporary discrepancies may occur as 
discussed in B.5.3). The 6-bit fine time field shall be set to all 1s when time is not known more 
accurately than within 1 minute (i.e., time quality of six or seven). When a time synchronization 
protocol (see B.5.5) is employed to obtain more accurate time, the fine time field shall be set to 
the time obtained using this protocol and incremented as described in B.5.3. The fine time field 
shall always be a multiple of the PI length, and shall be aligned to PI boundaries (e.g., with a 2- 
second PI, fine time shall always be even). The word field shall be used to count words within a 
PI, as specified in B.5.3. The frequency field shall be formatted in accordance with figure B-3. 
Each 4-bit field shall contain one binary-coded decimal digit of the frequency of the current 
protected transmission. Regardless of time quality, the fine time field shall be set all 1s for the 
unclassified application level of LP. 


B.5.3 Procedure for 2G ALE. 

The procedure to be employed in protecting transmissions consisting entirely of 24-bit ALE 
words is presented in B.5.3.1 and B.5.3.2. When a radio is neither transmitting nor receiving, the 
PI number shall be incremented as follows. When using linking protection level AL-2 and local 
time quality (see Appendix A, A.5.6.4.6) is “5” or better, the fine time field shall be incremented 
at the end of each PI by the length of the PI, modulo 60. When the fine time field rolls over to 
“0,” the coarse time field shall be incremented, modulo 1440. At midnight, the coarse and fine 
time fields shall be set to “0,” and the date and month fields updated. When using linking 
protection level AL-1, or when the local time quality (see appendix A, A.5.6.4.6) is “6” or “7,” 
the fine time field shall contain all “1s,” and the coarse time field shall be incremented once per 
minute, modulo 1440. At midnight, the coarse time field shall be set to “0”, and the date and 
month fields updated. Whenever the local time uncertainty is greater than the PI, the system 
shall: 


a. Present an alarm to the operator. 
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b. Optionally, also attempt resynchronization (if enabled). The first attempt at 
resynchronization shall use the current fine seed. If this fails, the system shall use a coarse 
seed for subsequent attempts. 


Example Seed 


Date=8 May Time=15:57:34 Word=0 Frequency=1755 kHz 


a. 
rr ee ee 


a ed 
0101 01110111101 000000 0000 0000 0001 0111 0101 
01000 100010 00 01010000 

1 9 10 26 ey 64 


11 


c 
es re ee 
es ee 
| Coarse Time | __Fine Time __| 


Coarse Time Fine Time 


01110111101 100010 


10 26 
d 


Pee gad eee Wie ee es ee gee eed 


37 40 41 44 45 48 49 82: D3 S07 57 60 61 64 


FIGURE B-3. Seed formats. 
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B.5.3.1. Transmitting station. 

Each word to be transmitted shall be encrypted by the scrambler using the current seed 
information. In the course of a transmission, the protocol described below may cause a 
discrepancy between the TOD fields in the seed and the real time. Such discrepancy shall be 
allowed to persist until the conclusion of each transmission, whereupon the TOD fields of the 
seed shall be corrected. The word number field “w” shall be as follows: 


a. During the scanning call phase (T;.) of a call, or throughout a sound, the calling stations 
shall alternate transmission of words encrypted using w = 0 and w= 1. The first word of Tc 
shall begin with w = 0 or w = 1, as required, such that the last word of Ts, is encrypted using 
w= 1. The TOD used during T,, shall change as required to keep pace with real time, except 
that TOD shall only change when w = 0. Words encrypted with w = 1 shall use the same 
TOD as the preceding word. 


b. At the beginning of the leading call phase (T),) of a call (which is the beginning of a 
single-channel), the first word shall be encrypted using w = 0 and the correct TOD for the 
time of transmission of that word. 


c. All succeeding words of the call shall use succeeding word numbers up to and including 
W = Wmax- For the word following a word encrypted with w = Wmax, the TOD shall be 
incremented and w shall be reset to 0. 


(1) Wmax = 2 for a 1-second PI. 
(2) Wimax = 5 for a 2-second PI. 
(3) Wimax = 153 for a 60-second PI. 


d. Responses and all succeeding transmissions shall start with w = 0 and the current 
(corrected) TOD, with these fields incremented as described in paragraph c above for each 
succeeding word. 


Figure B-4 illustrates the permissible TOD with combinations for a transmitting station using a 


60 second (Wimax=153) and a 2-second PI (Wmax = 5), and the permissible sequences of these 
combinations. Sounds are protected in the same fashion with T,, in place of Tic. 
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Other than scanning call 


Other than scanning call 


FIGURE B-4. Transmitting and receiving stations state diagram. 
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Word sync 
during T,, 


Word sync (other than scanning call) 


Cc. 


Word sync 


Boring: Tee Word sync (other than scanning call) 


d. 


FIGURE B-4. Transmitting and receiving stations state diagram (continued). 


B.5.3.2 Receiving station. 

Because of the possibility of acceptable decodes under multiple TOD/word number 
combinations, receivers shall attempt to decode received words under all allowed combinations 
(the current and adjacent PIs (future and past), and both w = 0 and w = 1) when attempting to 
achieve word synchronization with a calling station (six combinations). Stations prepared to 
accept time requests (see B.5.5.2.2) shall also attempt to decode received words using coarse 
TOD (fine time = all 1s, correct coarse time only) with both w = 0 and w = 1 (eight combinations 
total). All valid combinations shall be checked while seeking word sync. After achieving word 
sync, the number of valid combinations is greatly reduced by the link protection 
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protocol. Figure B-4 illustrates the permissible TOD/w sequences for a receiving station using a 
60-second PI and a 2-second PI respectively, after word sync is achieved. Note that unlike the 
transmitter, the receiving station state machine may be non-deterministic. For example, when in 
Tse and in state N/1, a received word may yield valid preambles and ASCII when decrypted using 
all of the valid combinations: N/O, (N + 1)/0, and N/2 (the latter implying that T), started two 
words previously), and will therefore, be in three states at once until the ambiguity is resolved by 
evaluating the decrypted words for compliance with the LP and ALE protocols under the valid 
successor states to these three states. Stations using a PI of 2 seconds or less shall not accept 
more than one transmission encrypted using a given TOD, and need not check combinations 
using that TOD. For example, if a call is decrypted using TOD = N, no TOD before N+1 is valid 
for the acknowledgment. 


B.5.3.3 Message sections. 
All ALE words shall be protected including message text. 


B.5.3.4 Data block message (DBM) mode. 


a. A DBM data block contains an integral number of 12-bit words, the last of which 
comprises the least significant 12 bits of a cyclic redundancy check (CRC). These 12-bit 
words shall be encrypted in pairs, with the first 12-bit word presented to the LPCM by the 
ALE protocol module as the more significant of the two. When a data block contains an odd 
number of 12-bit words (i.e., basic DBM data block and extended DBM data blocks with 
odd N), the final 12-bit word shall not be encrypted, but shall be passed directly to the FEC 
sublayer. 


66. 29 


b. The word number field “w” of the seed shall be incremented only after three pairs of 
12-bit words have been encrypted (rather than after every 24-bit word as in normal 
operation), except that the word number “w” shall be incremented exactly once after the last 
pair of 12-bit words in a DBM data block is encrypted, whether or not it was the third pair to 
use that word number. As usual, TOD shall be incremented whenever “‘w” rolls over to 0. 


B.5.4 Procedure for 3G ALE - not tested (NT). 

Linking protection for 3G ALE shall employ the same algorithms, seed format, and procedures as 
for 2G, except as specified in the following paragraphs. For definitions of terms used here that 
are specific to 3G ALE, see Appendix C. 


B.5.4.1 Encryption of 3G protocol data units (PDU). 

The first 2 bits of each 26-bit thrid-generation ALE PDU shall be sent without encrypting. The 
remaining 24 bits shall be encrypted in the same manner as 24-bit 2G ALE words. AL-1 and 
AL-2 shall use the SoDark-3 Algorithm (see B.5.7.1 and B.5.7.2) for encrypting 3G ALE PDUs. 
3G traffic manager, synchronization manager, and link maintenance PDUs shall be encrypted 
using the SoDark-6 algorithm (see B.5.7.3 and B.5.7.4). 


B.5.4.2 Procedure for synchronous-mode 3G ALE. 
When a network is operating in synchronous mode, stations are inherently synchronized to within 
50 ms. The protection interval for synchronous mode 3G ALE is therefore the length of one slot 
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(800 ms). The PI field in the seed shall be used as a 17-bit integer rather than as an 11-bit coarse 
time and a 6-bit fine time field. This 17-bit PI field shall contain the number of 800 ms slots that 
have elapsed since midnight (network time). The word number field in the seed shall always be 
00000000. The date fields shall reflect the current network date. The frequency field shall 
indicate the frequency on which the protected PDU is sent. Synchronous-mode 3G ALE nodes 
shall ignore any synchronous-mode Probe PDU (i.e., a Probe PDU that is not preceded by 
Scanning Call PDUs) which is not encrypted using the current PI number. 


B.5.4.3, Procedure for asynchronous-mode 3G ALE. 
Asynchronous 3G handshakes shall be protected using the procedure in B.5.3 that has been 
modified as follows. 


B.5.4.3.1 Protected 3G asynchronous-mode scanning call. 

The probe PDU that concludes a 3G asynchronous-mode call shall be encrypted using word 
number = 2. Scanning call PDUs shall be encrypted using alternating word numbers 0 and 1. 
The word number used in encrypting the first scanning call PDU shall be selected so that the 
scanning call PDU sent immediately before the probe PDU is encrypted using word number = 1. 


B.5.4.3.2 Protected 3G asynchronous-mode response. 
The handshake PDU that follows an asynchronous-mode call shall be encrypted using the current 
TOD with word number = 3. 


B.5.4.4 Protected 3G PI progression. 
3G ALE nodes shall not accept PDU sequences in which the TOD used to encrypt a PDU is 
earlier than the TOD used to encrypt a preceding PDU of that sequence. 


B.5.5 Time protocols. 

The following shall be employed to synchronize LP time bases. The time service protocols for 
active time acquisition, both protected (B.5.5.2) and non-protected (B.5.5.3), are mandatory for 
all implementations of LP. 


B.5.5.1 Time exchange word format. 
See Appendix A, A.5.6.4.3. 


B.5.5.2 Active time acquisition (protected). 

A station that knows the correct date and time to within | minute may attempt to actively acquire 
time from any station with which it can communicate in protected mode by employing the 
protocol in the following paragraphs. The quality of time so acquired is necessarily at least one 
grade more uncertain than that of the selected time server. A station that does not know the 
correct date and time to within 1 minute may nevertheless employ this protected protocol by 
repeatedly guessing the time until it successfully communicates with a time server. 


B.5.5.2.1 Time Request call (protected). 
A station requiring fine time shall request the current value of the network time by transmitting a 
Time Request call, formatted as follows. (In principle, any station may be asked for the time, but 
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some stations may not be programmed to respond, and others may have poor time quality. Thus, 
multiple servers may need to be tried before sufficient time quality is achieved.) 


TO <time server> CMD Time Is <time> DATA <coarse time> 
REP <authenticator> TIS <requester>. 


The Time Is command shall be immediately followed by a coarse time word and an 
authentication word. The authenticator shall be generated by the exclusive-or of the command 
word and the coarse time word, as specified in Appendix A, A.5.6.4.4. The Time Request call 
transmission shall be protected using the procedure specified in B.5.3.1 and B.5.3.2. When 
acquiring time synchronization, the coarse seed (fine time field in the seed set to all 1s) current at 
the requesting station shall be used. When used to reduce the time uncertainty of a station already 
in time sync, the current fine seed shall be used. 


B.5.5.2.2 Time Service response (protected). 
A station which receives and accepts a Time Request call shall respond with a Time Service 
response formatted as follows: 


TO <requester> CMD Time Is <time> DATA <coarse time> 
REP <authenticator> TWAS <time server>. 


The Time Is command shall be immediately followed by a coarse time word and an 
authentication word. The authenticator shall be generated by the three-way exclusive-or of the 
command word and the coarse time word from this transmission and the authentication word 
(including the REP preamble) from the requester, as specified in Appendix A, A.5.6.4.5. The 
entire Time Service response shall be protected as specified in B.5.3.1 and B.5.3.2 using the time 
server’s current coarse seed if the request used a coarse seed, or the current fine seed otherwise. 
The seed used in protecting a Time Service response may differ from that used in the request that 
caused the response. A time server shall respond only to the first Time Request call using each 
fine or coarse seed; 1.e., one coarse request per minute and one fine request per fine PI. 
Acceptance of time request may be disabled by the operator. Stations prepared to accept coarse 
Time Request commands shall decrypt the initial words of incoming calls under eight (vs. six) 
possible seeds: w = 0 and w = | with the current coarse TOD, and with the current fine TOD +1 
PI. (Note that only one coarse TOD is checked vs. three fine TODs.) 


B.5.5.2.3 Time Server request (protected). 

A time server may request authenticated time from the original requestor by returning a Time 
Server request, which is identical to the Time Service response as given above except that the 
TWAS termination is replaced by TIS. The original requester shall then respond with a Time 
Service response, as above, with an authenticator generated by the three-way exclusive-or of the 
command word and the coarse time word from its Time Service response and the authentication 
word (including the REP preamble) from the Time Server request, as specified in Appendix A, 
A.5.6.4.5. 
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B.5.5.2.4 Authentication and adjustment (protected). 

A station awaiting a Time Service response shall attempt to decrypt received words under the 
appropriate seeds. If the request used a coarse seed, the waiting station shall try the coarse seeds 
used to encrypt its request, with w = 0 and w = 1, and those corresponding to 1 minute later. If 
the request used a fine seed, the waiting station shall try the usual six seeds: w = 0 and w= 1, 
and those corresponding to 1 minute later. If the request used a fine seed, the waiting station 
shall try the usual six seeds: w = 0 and w = 1 with the current fine TOD +1 PI. Upon successful 
decryption of a Time Service response, the requesting station shall exclusive-or the received 
command and coarse time words with the authentication word it sent in its request. Ifthe 21 
least significant bits of the result match the corresponding 21 bits of the received authentication 
word, the internal time shall be adjusted using the time received in the Time Is command and 
coarse time word, and the time uncertainty shall be set in accordance with Appendix A, 
A.5.6.4.6. 


B.5.5.3. Active time acquisition (non-protected). 

A station that does not know the correct date and time to within 1 minute may attempt to actively 
acquire time from any station with which it can communicate in non-protected mode by 
employing the protocol in the following paragraphs. Because time is not known in this case with 
sufficient accuracy to employ LP, the entire exchange takes place in the clear, with the 
authentication procedure as the only barrier against decryption. 


B.5.5.3.1 Time Request call (non-protected). 
A station requiring time shall request the current value of the network time by transmitting a non- 
protected Time Request call, formatted as follows: 


TO <time server> CMD Time Request DATA <coarse time> 
REP <random #> TIS <requestor>. 


The Time Request command shall be immediately followed by a coarse time word, followed by 
an authentication word containing a 21-bit number, generated by the requesting station in such a 
fashion that future numbers are not predictable from recently used numbers from any net 
member. Encrypting a function of a radio-unique quantity and a sequence number that is 
incremented with each use (and is retained while the radio is powered off) may meet this 
requirement. 


B.5.5.3.2 Time Service response (non-protected). 
A station that receives and accepts a non-protected Time Request call shall respond with a non- 
protected Time Service response formatted as follows: 


TO <requester> CMD Time Is <time> DATA <coarse time> 
REP <authenticator> TWAS <time server>. 


The Time Is command shall be immediately followed by a coarse time word and an 


authentication word. The 21-bit authenticator shall be generated by encrypting the 24-bit result 
of the three-way exclusive-or of the command word and the coarse time word from this 
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transmission and the entire random number word (including the REP preamble) from the 
requester, as specified in Appendix A, A.5.6.4.5. The encryption shall employ the AL-1 and AL- 
2 algorithm and a seed containing the time sent and w = all 1s. The least-significant 21 bits of 
this encryption shall be used as the authenticator. A time server shall respond only to the first 
error-free non-protected Time Request call received each minute (according to its internal time). 
Acceptance of non-protected time requests may be disabled by the operator. 


B.5.5.3.3 Authentication and adjustment (non-protected mode). 

Upon receipt of a non-protected Time Service response, the requesting station shall exclusive-or 
the received coarse time word with the received Time Is command word. Then exclusive-or the 
result with the entire random number word it sent in its Time Request call, and encrypt this result 
using w = all 1s and the coarse time contained in the Time Service response. If the 21 least 
significant bits of the result match the corresponding 21 bits of the received authentication word, 
the internal time shall be adjusted using the received coarse and fine time, and the time 
uncertainty shall be set in accordance with Appendix A, A.5.6.4.6. 


B.5.5.4 Passive time acquisition (optional). 

As an alternative to the active time acquisition protocols specified above, stations may attempt to 
determine the correct network time passively by monitoring protected transmissions. Regardless 
of the technique used to otherwise accept or reject time so acquired, passive time acquisition 
shall include the following constraints: 


a. Local time may only be adjusted to times within the local window of uncertainty. 
Received transmissions using times outside of the local uncertainty window shall be ignored. 


b. Local time quality shall be adjusted only after receipt of transmissions from at least two 
stations, both of which include time quality values, and whose times are consistent with each 
other within the windows implied by those time qualities. 


A passive time acquisition mechanism may also be used to maintain network synchronization 
once achieved. Passive time acquisition is optional, and if provided, the operator shall be able to 
disable it. 


B.5.5.5 Time broadcast. 
To maintain network synchronization, stations shall be capable of broadcasting unsolicited Time 
Is commands to the network, periodically or upon request by the operator: 


TO <net> CMD Time Is <time> DATA <coarse time> 
REP <authenticator> TWAS <time server>. 


The Time Is command shall be immediately followed by a coarse time word and an 
authentication word. The authenticator shall be generated by the exclusive-or of the command 
word and the coarse time word from this transmission as specified in Appendix A, A.5.6.4.4. If 
the broadcast is made without LP (i1.e., in the clear), the authenticator must be encrypted as 
described in Appendix A, A.5.6.4.5 to provide any authentication. The use of an authenticator 
that does not depend on a challenge from a requesting station provides no protection against 
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playback of such broadcasts. A station receiving such broadcasts must verify that the time and 
the time uncertainty that the broadcasts contain are consistent with the local time and uncertainty 
before such received time is at all useful. 


B.5.5.6 Advanced time distribution protocols. 
Advanced time exchange protocols for application levels 3 and 4 will be addressed as required 
with future upgrades of MIL-STD-188-141. 


B.5.6 The Lattice Algorithm. 
The Lattice Algorithm is designed specifically for the encryption of 24-bit ALE words. It uses a 
56-bit key (7 bytes), and the 8-byte seed described in B.5.2.3, Seed format. 


NOTE: The author makes no claim of proprietary rights in this algorithm. All are free to 
implement it without royalty. 


B.5.6.1 Encryption using the Lattice Algorithm. 

A schematic representation of the algorithm is shown in figure B-5. The algorithm operates on 
each of the 3 bytes of the 24-bit word individually. At each step, here termed one “round” of 
processing, each byte is exclusive-ored with one or both of the other data bytes, a byte of key, 
and a byte of seed, and the result is then translated using the 256x8 bit substitution table ("S- 
box") listed in table B-I. Eight rounds shall be performed. Mathematically, the encryption 
algorithm works as follows: 


1. Let f(*) be an invertible function mapping {0..255} -> {0..255}. 

2. Let V bea vector of key variable bytes and S be a vector of TOD/frequency "seed" 
bytes. Starting with the first byte in each of V and S, perform eight "rounds" of 
the sequence in 4 below, using the next byte from V and S (modulo their lengths) 
each time a reference to V[ ] and S[ | is made. 

3. Let A be the most significant of the three-byte input to each round of encryption, 
B be the middle byte, and C be the least significant byte, and A’, B', and C' be the 
corresponding output bytes of each round. 

4. Then for each round, 

A'=f(A+B+V[]+S[]) 
C'=f(C+B+V[]+S[]) 
B'=f(A'+B+C'+ V[]+S[)) 


The 24-bit output of the encryption algorithm consists of, in order of decreasing significance, the 
bytes A’, B’, and C’ resulting from the eighth round of encryption. 


B.5.6.2 Decryption using the Lattice Algorithm. 
The decryption algorithm simply inverts the encryption algorithm. Note that the starting point in 
the V and S vectors must be pre-computed, and that the V and S bytes are used in reverse order. 


1. Let g(°) be the inverse of the f(+) used for encryption (see table B-II). 
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2. Starting with the last elements of the V and S vectors used in encryption, perform 
eight rounds of the following decryption steps, working backward through the V 
and S vectors. 

3. Let A’ be the most significant of the 3-byte input to each round of decryption, B’ 
be the middle byte, and C’ be the least significant byte, and A, B, and C be the 
corresponding output bytes of each round. 

4. B=g9(B))+A'+C'+V[]+S[] 

C=29(C')+B+V[]+Sf[ ] 
A=g(A')+B+V[]+S[] 


The 24-bit output of the decryption algorithm consists of, in order of decreasing significance, the 
bytes A, B, and C resulting from the eighth round of decryption. 


253 


MIL-STD-188-141B 
APPENDIX B 


FIGURE B-5. Lattice Algorithm schematic diagram (encryption). 
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B.5.6.3. Encryption and decryption tables. 

The 256 -> 256 mapping tables B-I and B-II for use in linking protection are given below. To 
use these tables, use the most significant 4 bits of the input byte to select a row in the table, and 
the least significant 4 bits to select a column. The output byte is contained at the selected 
location. 


TABLE B-I. Encryption table, 


9c f2 14 cl 8e cb b2 65 97 Ta 60 17 92 F9 78 41 
07 4c 67 6d 66 4a 30 7d 53 9d b5 be 3 ca fl 04 
03 ec do 38 BO ed ad c4 dd 56 42 bd a0 de 1b 81 
55 44 5a e4 50 DC 43 63 09 5c 74 cf Oe ab Id 3d 
6b 02 5d 28 e7 c6 ee b4 d9 7c 19 3e 5e 6c d6 6e 
2a 13 a5 08 b9 2d BB a2 d4 96 39 e0 ba d7 82 33 
0d 5f 26 16 fe 22 af 00 11 c8 9e 88 8b al 7b 87 
27 E6 c7 94 dl 5b 9b f0 of db el 8d d2 If 6a 90 
f4 18 91 59 01 bl FC 34 3c 37 47 29 e2 64 69 24 
0a 2f 73 71 a9 84 8c a8 a3 3b E3 E9 58 80 a7 D3 
b7 c2 Ic 95 le 4d 4f 4E fb 76 fd 99 c5 C9 8 2e 
8a df f5 49 £3 6f 8f e5 EB F6 25 d5 31 c0 57 72 
aa 46 68 0b 93 89 83 70 ef a4 85 f8 Of b3 AC 10 
62 ce 61 40 f7 fa 52 7f ff 32 45 20 79 ce ea be 
cd 15 21 23 D8 b6 0c 3f 54 1A bf 98 48 3a 75 77 
2b ae 36 da Te 86 35 51 05 12 bs a6 9a 2C 06 4b 


255 


67 
cf 
db 
16 
d3 
34 
0a 
c7 
9d 
7F 
2c 
24 
bd 
22 
5b 
77 


20 
51 
E3 
5f 
36 
18 
37 
92 
c6 
c4 
98 
cd 
Ic 
OF 
9A 
b4 


If 
02 
8f 
87 
31 
e8 
8d 
3a 
95 
73 
c9 
47 
27 
58 
33 
80 


TABLE B-II. Decryption table 
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10 
0b 
70 
89 
8a 
BE 
12 
ef 
6f 
08 
9e 
a0 
72 
5d 
44 
d4 


256 


53 
81 
43 
23 
ec 
9c 
c2 
Oe 
6b 
EB 
97 
fa 
69 
E4 
ae 


cb 


e6 
a2 
Fd 
88 
11 
39 
4d 
49 
96 
00 
CE 
1b 
dl 
35 
21 
86 


60 
3e 
55 
3f 
a5 
42 
13 
17 
7b 
19 
26 
2b 
e0 
28 
25 


aa 


3c 
a4 
af 
4b 
AZT 
4c 
4f 
£4 
04 
6a 
fl 
df 
dd 
2d 
46 
64 


cc 
7d 
91 
e7 
a6 
61 
b5 
d7 
b6 
78 
66 
ea 
3b 
bl 
c8 
d8 
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B.5.6.4 Lattice Algorithm examples. 


Key variable = c2284alce7be2f 


seed = 543bd88000017550 (w=0) 


Encrypt 54e0cd ( <TO> SAM ) 
Step A B Cc 
0 54 E0 CD 
1 DO 72 1D 
2 1D 48 3C 
3 Al DB OC 
4 98 7C 6D 
5 39 10 3D 
6 13 AA B4 
7 FC 82 27 
8 CO D7 05 


Result:  COD705 


seed = 543bd88040017550 = (w=1) 


Encrypt 54E0CD ( <TO> SAM ) 
Step A B i: 
0 54 E0 CD 
1 DO 72 1D 
2 1D 3D EF 
3 EI F8 6B 
4 AO A2 
5 6E 32 AO 
6 BO B4 E2 
7 CF CB 11 
8 70 84 34 


Result: 708434 


seed = 543b6d88080017550 = (w=2) 
Encrypt b2a7c5 ( <TIS> JOE ) 

Step A B iS 

0 B2 A7 C5 

1 59 47 E6 

2 9 BF 83 

3 D B8 E8 

4 53 ED AY 

5 F4 55 9 

6 32 25 FA 

7 DD 5D 15 

8 28 ED 4A 


Result: 28ED4A 
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Decrypt COD705 
Step A B Cc 
0 CO D7 05 
1 FC 82 27 
2 Id AA B4 
3 39 10 3D 
4 98 7C 6D 
a) 41 DB OC 
6 1D 48 3C 
7) DO 72 1D 
8 54 EO CD 
Result: 54E0CD 
Decrypt 708434 
Step A B Cc 
0 70 84 34 
1 CF CB 11 
2 BO B4 E 
3 6E 32 AO 
4 1] AQ A2 
5 E F8 6B 
6 1D 3D BF 
7 DO 72 1D 
8 54 EO CD 
Result: 54E0OCD 
Decrypt 28ED4A 
Step A B iS 
0 28 ED 4A 
1 DD 5D 15 
2 32 25 FA 
3 F4 39 9 
4 53 ED A9 
5 DI B8 E 
6 97 BF 83 
7 59 47 E6 
8 B2 A7 C5 
Result: B2A7C5 


MIL-STD-188-141B 
APPENDIX B 


258 


MIL-STD-188-141B 
APPENDIX B 


B.5.7 The SoDark Algorithm (NT). 

The SoDark Algorithm is designed specifically for the encryption of 3G control PDUs. It uses a 
56-bit key (7 bytes), and the 8-byte seed described in B.5.2.3 Seed format. The SoDark-3 variant 
is designed for 24-bit words, while the SoDark-6 variant is designed for 48-bit words. 


NOTE: The author makes no claim of proprietary rights in this algorithm. All are free to 
implement it without royalty. 


B.5.7.1 Encryption using the SoDark-3 Algorithm. 

The SoDark-3 Algorithm is designed specifically for the encryption of 3G ALE PDUs. It shall 
be applied to the 24 least-significant bits of each such PDU. A schematic representation of the 
SoDark-3 algorithm is shown in figure B-6. The algorithm operates on each of the 3 bytes of the 
24-bit word individually. At each step, here termed one “round” of processing, each byte is 
exclusive-ored with one or both of the other data bytes, a byte of key, and a byte of seed, and the 
result is then translated using the 256x8 bit substitution table ("S-box") listed in table B-I. 
Sixteen rounds shall be performed. 


Mathematically, the encryption algorithm works as follows: 


1. Let f(*) be an invertible function mapping {0..255} -> {0..255}. 

2. Let V bea vector of key variable bytes and S be a vector of TOD/frequency "seed" 
bytes. Starting with the first byte in each of V and S, perform sixteen "rounds" of 
the sequence in 4 below, using the next byte from V and S (modulo their lengths) 
each time a reference to V[ ] and S[ | is made. 

3. Let A be the most significant of the 3-byte input to each round of encryption, B be 
the middle byte, and C be the least significant byte, and A', B', and C' be the 
corresponding output bytes of each round. 

4. Then for each round, 

A'=f(A+B+V[]+S[]) 
C'=f(C+B+V[]+S[]) 
B'=f(A'+B+C'+ V[]+S[]) 


The 24-bit output of the encryption algorithm consists of, in order of decreasing significance, the 
bytes A’, B’, and C’ resulting from the sixteenth round of encryption. 


B.5.7.2 Decryption using the SoDark-3 Algorithm. 
The decryption algorithm simply inverts the encryption algorithm. Note that the starting point in 
the V and S vectors must be pre-computed, and that the V and S bytes are used in reverse order. 


259 


MIL-STD-188-141B 
APPENDIX B 


Let g(*) be the inverse of the f(*) used for encryption (see table B-II). 

Starting with the last elements of the V and S vectors used in encryption, perform 

sixteen rounds of the following decryption steps, working backward through the V 

and S vectors. 

3. Let A’ be the most significant of the 3-byte input to each round of decryption, B’ 
be the middle byte, and C’ be the least significant byte, and A, B, and C be the 
corresponding output bytes of each round. 

4. B=g9(B')+A'+C'+V[]+S[] 

C=g(C)+B+V[]+S[] 

A=g(A')+B+V[]+S[] 


ee 


The 24-bit output of the decryption algorithm consists of, in order of decreasing significance, the 
bytes A, B, and C resulting from the sixteenth round of decryption. 


B.5.7.3 Encryption using the SoDark-6 Algorithm. 

The SoDark-6 Algorithm is designed specifically for the encryption of 3G PDUs that use Burst 
Waveform | (BW1), including traffic setup, synchronization management, and link maintenance 
PDUs. It shall be applied to the 48 bits of each such PDU. A schematic representation of the 
SoDark-6 algorithm is shown in figure B-7. The algorithm operates on each of the 6 bytes of the 
48-bit PDU individually. At each step, here termed one “round” of processing, each byte is 
exclusive-ored with two of the other data bytes, a byte of key, and a byte of seed, and the result is 
then translated using the 256x8 bit substitution table ("S-box") listed in table B-I. Sixteen rounds 
shall be performed. 
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FIGURE B-6. SoDark-3 Algorithm schematic diagram (encryption). 
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Mathematically, the encryption algorithm works as follows: 


1. Let f(*) be an invertible function mapping {0..255} -> {0..255}. 

2. Let V bea vector of key variable bytes and S be a vector of TOD/frequency "seed" 
bytes. Starting with the first byte in each of V and S, perform sixteen "rounds" of 
the sequence in 4 below, using the next byte from V and S (modulo their lengths) 
each time a reference to V[ ] and S[ ] is made. 

3. Let A be the most significant of the 6-byte input to each round of encryption, B, 
C, D, and E be the middle bytes in descending order of significance, and F be the 
least significant byte, and A', B', C’, D’, E’ and F' be the corresponding output 
bytes of each round. 

4. Then for each round, 

A'=f(A+B+F+V[]+S[]) 
C'=f(B+C+D+V[]+S[]) 
E'=f(E+D+F+V[]+S[]) 
B'=f(A'+B+C'+ V[]+S[]) 
D'=fC'+D+E'+V[]+S[) 
F'=f(E'+ F+ A'+ V[]+S[ ]) 


The 48-bit output of the encryption algorithm consists of, in order of decreasing significance, the 
bytes A’, B’, C’, D’, E’ and F’ resulting from the sixteenth round of encryption. 


B.5.7.4 Decryption using the SoDark-6 Algorithm. 
The decryption algorithm simply inverts the encryption algorithm. Note that the starting point in 
the V and S vectors must be pre-computed, and that the V and S bytes are used in reverse order. 


1. Let g(¢) be the inverse of the f(+) used for encryption (see table B-II). 

Starting with the last elements of the V and S vectors used in encryption, perform 
sixteen rounds of the following decryption steps, working backward through the V 
and S vectors. 

3. Let A’ be the most significant of the 6-byte input to each round of decryption, B’, 
C’, D’, and E’ be the middle bytes in descending order of significance, and F’ be 
the least significant byte, and A, B, C, D, E and F be the corresponding output 
bytes of each round. 

4. B=g(B')+A'+C'+V[]+S[] 

D=g(D)+C'+E'+ V[]+S[] 
F = g(F')+ E'+ A'+ V[]+S[] 
E=g(F)+D+F+V[]+S[] 
C=9(C)+B+D+V[]+S[] 
A=g(A')+F+B+V[]+S[ ] 


The 48-bit output of the decryption algorithm consists of, in order of decreasing significance, the 
bytes A, B, C, D, E, and F resulting from the sixteenth round of decryption. 
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FIGURE B-7. SoDark-6 Algorithm schematic diagram (encryption). 
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C.1 GENERAL. 


C.1.1 Scope. 

This appendix contains the requirements for the prescribed protocols and directions for the 
implementation and use of third generation (3G) high frequency (HF) radio technology including 
advanced automatic link establishment (ALE), automatic link maintenance, and high- 
performance data link protocols. The inter-relationship of the technology specified in this 
appendix to other HF automation standards is shown in figure C-1. 


HF Subnetwork Layer and Higher Layers 
(Appendix D) 


2nd Generation 3rd Generation 
IHF Link Automation HF Link Automatio 

(Appendix A and = (This Appendix) 
MIL-STD-188-110) 


HF Radio 
(MIL-STD-188-141) 


FIGURE C-1. Scope of 3G technology. 


C.1.2 Applicability. 
3G technology provides advanced technical capabilities for automated HF radio systems. This 


advanced technology improves on the performance of similar techniques described elsewhere in 
this standard. Thus, 3G technology may not be required by some users of HF radio systems. 
However, if the user has a requirement for the features and functions described herein, they shall 
be implemented in accordance with the technical parameters specified in this appendix. 


C.2 APPLICABLE DOCUMENTS. 


C.2.1 General. 

The documents listed in this section are specified in C.4 and C.5 of this appendix. This section 
does not include documents cited in other sections of this standard or recommended for 
additional information or as examples. While every effort has been made to ensure the 
completeness of this list, document users are cautioned that they must meet all specified 
requirements documents cited in C.4 and C.5 of this appendix, whether or not they are listed 
here. 
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C.2.2 Government documents. 


C.2.2.1 Specifications, standards, and handbooks. 

The following specifications, standards, and handbooks form a part of this document to the 
extent specified herein. Unless otherwise specified, the issues of these documents are those 
listed in the issue of the Department of Defense Index of Specifications and Standards (DODISS) 
and supplement thereto, cited in the solicitation. 


STANDARDS 
FEDERAL 
FED-STD-1037 Telecommunications: Glossary of 
Telecommunication Terms 
MILITARY 
MIL-STD-188-110 Interoperability and Performance Standards 


for HF Data Modems 


Unless otherwise indicated, copies of federal and military specifications, standards, and 
handbooks are available from the Naval Publications and Forms Center, ATTN: NPODS, 5801 
Tabor Avenue, Philadelphia, PA 19120-5099. 


C.2.2.2 Other Government documents, drawings, and publications. 
The following other Government documents, drawings, and publications form a part of this 
document to the extent specified herein. Unless otherwise specified, the issues are those cited in 
the solicitation. 

None. 


C.2.3 Non-Government publications. 

The following documents form a part of this document to the extent specified herein. Unless 
otherwise specified, the issues of the documents which are DoD adopted are those listed in the 
issues of the DODISS cited in the solicitation. Unless otherwise specified, the issues of the 
documents not listed in the DODISS are the issues of the documents cited in the solicitation (see 
6.3). 


INTERNATIONAL STANDARDIZATION DOCUMENTS 


North Atlantic Treaty Organization (NATO) Standardization Agreements 


(STANAGs) 
STANAG 4285 Characteristics of 1200/2400/3600 bits per second 
Single Tone modulators/demodulators for HF 
Radio Links 
STANAG 4197 Modulation and Coding Characteristics that Must 


be Common to Assure Interoperability of 2400 BPS 
Linear Predictive Encoded Digital Speech 
Transmitted Over HF Radio Facilities 
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STANAG 4198 Parameters and Coding Characteristics That Must 


be Common to Assure Interoperability of 2400 BPS 
Linear Predictive Encoded Digital Speech 


International Telecommunications Union (ITU) 
Radio Regulations | Recommendtion for Fixed Service, Use of High 
ITU-R F.520-2 Frequency Ionospheric Chanel Simulators 


C.2.4 Order of precedence. 


In the event of a conflict between the text of this document and the references cited herein, the 
text of this document takes precedence. Nothing in this document, however, supersedes 
applicable laws and regulations unless a specific exemption has been obtained. 


C.3 DEFINITIONS. 


C.3.1 Standard definitions and acronyms. 


C.3.2 Abbreviations and acronyms. 
The abbreviations and acronyms used in this document are defined below. Those listed in the 


current edition of FED-STD-1037 have been included for the convenience of the reader. 


2G 

2G ALE 
3G 

3G ALE 
ACK 
ACQ-ALE 
AGC 
ALE 
ALM 
ARQ 
ASCII 
AWGN 
bps 
BWO 
BWI 
BW2 
BW3 
BW4 
CLC 
CM 
CMD 
CONF 
CRC 
CSU 


xed etTHMtOvsvosp RTA Boe mOoa0C®m 


second generation 

second generation automatic link establishment 
third generation 

third generation automatic link establishment 
acknowledgment 

alternative quick call -automatic link establishment 
automatic gain control 

automatic link establishment 

automatic link maintenance 

automatic repeat request 

American Standard Code for Information Interchange 
additive white gaussian noise 

bits per second 

Burst Waveform 0 

Burst Waveform 1 

Burst Waveform 2 

Burst Waveform 3 

Burst Waveform 4 

circuit link controller 

Connection Manager 

ALE preamble word COMMAND 

confirm 

cyclic redundancy check 

Call SetUp 
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y dB decibel 
Z DO design objective 
aa EMCON Emission Control 
bb EOM End of Message 
ce FEC forward error correction 
dd FSK frequency shift keying 
ee GPS Global Positioning System 
ff HF high frequency 
gg HDL high-rate data link protocol 
hh HNMP HF Network Management Protocol 
il Hz Hertz 
ij LDL low-rate data link protocol 
kk Isb least-significant bit 
Il kHz kiloHertz 
mm MHZ megahertz 
nn ms millisecond 
00 msb most-significant bit 
pp NAK negative acknowledgment 
qq PDU protocol data unit 
Ir PN pseudo noise 
SS REQ request 
tt 1X receive 
uu S second 
vv SDU service data unit 
ww SNMP simple network management protocol 
XX SSB Single SideBand 
yy TERM Terminate 
ZZ TLC Transmit Level Control 
aaa ™ traffic management 
bbb TOD time of day 
ccc TRF Traffic 
ddd TSU Traffic SetUp 
eee TWAS ALE preamble word THIS WAS 
fff tx transmit 
gee UNL unlink 


C.3.3 Operating parameters. 
The operating parameters used in this appendix are collected here for the convenience of the 
reader. 


Symbol Parameter Name Default Value 
Tsym PSK symbol time 1/2400s_ 417 us 
Tylot Slot time 800 milliseconds (ms) 
Cc Number of scanned channels 
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M Number of repetitions of protocol data units (PDUs) 
per channel in asynchronous networks 1.3 
Tye Time for an asynchronous mode scanning call 
Tue Time for transmit level control settling 256/2400 s_ 106.7 ms 
Tpwo pre Time for Burst Waveform 0 preamble 384/2400 s = 160.0 ms 
Tpwo data Time for Burst Waveform 0 data 832/2400 s__ 346.7 ms 
D Current dwell channel 
T Seconds since midnight (network time) 
G Dwell group number 


Also see table C-XXV 3G-ALE Protocol Data for additional operating parameters. 


C.4 GENERAL REQUIREMENTS. 


C.4.1 Overview. 

The third-generation automatic link establishment (3G-ALE) protocol, the Traffic Management 
(TM) protocol, the High-Rate Data Link (HDL) and Low-Rate Data Link (LDL) protocols, and 
the circuit link management (CLC) protocol form a mutually-dependent protocol suite (see figure 
C-2). Compliance with this appendix requires compliant implementations of all of the protocols 
defined in this appendix (shown in shaded box in figure C-2). 


HF Subnetwork Layer and Higher Layers 


Session Manager 


(including Automatic Link Maintenance) 


Connection Traffic Data Link Circuit Link 
Management Management Protocols Management 
(3G-ALE) (TM) (HDL, LDL) (CLC) 


Physical Layer (Modem Waveforms BWO-BW4 and others) 


HF Radio (MIL-STD-188-141) 


FIGURE C-2. 3G HF protocol suite. 
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C.4.2 Frequency management. 


C.4.2.1 Calling and traffic channels. 

Frequencies assigned for use in 3G networks will be designated for use in calling, traffic, or both. 
Network managers should observe the following principles in assigning channels in these 
networks: 


e Use of a channel for both calling and traffic reduces performance in networks subject to 
heavy traffic loads. 


e Traffic channels should be assigned near calling channels so that the propagation 
characteristics of traffic channels are similar to those of the calling channels. 


e Calling channels should be assigned to scan lists (see Scanning below) in non- 
monotonic frequency order so that the available frequency range is covered several 
times during a single scan. For example, frequencies 3, 4, 5, 6, 8, 10, 11, 13, 18, and 23 
MHz might be scanned in the order 3, 6, 11, 23, 5, 10, 18, 4, 8, 13. 


Calling channels shall be assigned to the lowest-numbered channels, starting with channel 0. 
When C calling channels are scanned, the highest-numbered calling channel shall be C-1. 


C.4.2.2 External frequency management. 
Systems shall provide for management of frequency use via the network management interface 
(see Section 4.9). This capability shall include at least the following: 


e Assignment of frequencies to channels 
e Enabling and disabling of calling and traffic on each channel 
e Assignment of channels to scan list 


e =Entry of channel quality data 


NOTE: The network manager must assign the first three items uniformly network-wide. 


C.4.3 Network synchronization. 

3G systems shall include mechanisms to maintain synchronization among all local time bases in 
a network. When 3G-ALE is operating in synchronous mode, the difference between the earliest 
time and the latest time among the stations must not exceed 50 ms. In asynchronous networks, 
the permissible range of network times is determined by the current level of linking protection, if 
any. 


C.4.3.1 External synchronization. 

A means shall be provided to set the local time from a source such as a Global Positioning 
System (GPS) receiver. The internal time base shall differ by no more than 1 ms from the 
external source immediately after such a time update. Time base drift shall not exceed 1 part per 
million. 
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C.4.3.2 Over-the-air synchronization. 
When an external source of synchronization is not available, 3G systems shall maintain 
synchronization using the synchronization management protocol of C.5.2.7. 


C.4.4 Scanning. 
When not engaged in any of the 2G or 3G protocols, 3G systems shall continuously scan 


assigned channels, listening for 2G and 3G calls. They shall leave the scanning state when called 
or when placing a call, in accordance with the protocol behaviors specified in C.5.2.4 and 
C525: 


C.4.4.1 Synchronous mode. 

3G ALE synchronous-mode receivers shall scan at a synchronized rate of 4 seconds per channel. 
Stations shall be assigned to dwell groups by the network manager. Each dwell group shall listen 
on a different channel during each 4-second dwell period, in accordance with the following 
formula: 


D = ((T/4)+G) mod C 
where D = Dwell channel 
T = Seconds since midnight (network time) 
G = Dwell group number 
C = Number of channels in scan list 


Note that this yields channel numbers in the range 0 to C-1 in accordance with C.4.2.1. 


C.4.4.2 Asynchronous mode. 

3G systems using asynchronous mode 3G ALE shall scan assigned calling channels at a rate of at 
least 1.5 channels per second. (design objective (DO): scan at 10 channels per second, in which 
case the corresponding dwell period of 100 ms may be extended to up to 667 ms as required 
when evaluating received signals. Ifa BW0O preamble has not been detected within 667 ms, the 
system shall resume scanning.) 


C.4.5 3G addresses. 

3G systems use 11-bit binary addresses in the over-the-air protocols. These addresses shall be 
translated to and from second-generation addresses (call signs of up to 15 American Standard 
Code for Information Interchange (ASCII)-36 characters) for operator use. 


C.4.5.1 Synchronous mode address structure. 

The synchronous mode 3G-ALE protocol defines further structure within the 11-bit address 
space: the 5 least-significant bits (LSBs) of the address shall contain the dwell group number of 
the node, and the 6 most-significant bits (MSBs) shall contain the node’s member number within 
that group (see figure C-3). 
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6 bits 5 bits 
Member # Group # 


FIGURE C-3. Synchronous mode address structure. 


C.4.5.2 Net entry addresses. 

The member numbers from 111100 through 111111 (addresses 11110000000 through 
11111111111) are reserved for temporary use by stations calling into a network, and shall not be 
assigned to any network member. 


C.4.5.3, Multicast addresses. 

Multicast addresses form a distinct 6-bit address space, and shall be distinguished from 
individual addresses by their use only in multicast calls. When computing link IDs for use in 
multicast calls, the multicast address shall be placed in the most-significant six bits (member 
number portion in figure C-1), and the group number bit positions shall be filled with five bits set 
to 1. 


C.4.5.4 Node address assignments. 

Each node in a network shall be assigned a single 11-bit address that is distinct from all other 
node addresses in the network. This address shall be recognized by that node in individual and 
unicast calls. 


NOTE: When it is desired to be able to reach all network members with a single call, and 
network traffic is expected to be light, up to 60 network member stations may be assigned to 
one dwell group. However, this arrangement is subject to calling channel congestion. To 
support heavier call volume than the single-group scheme will support, the network 
members should be distributed into multiple dwell groups. 


C.4.5.5 Multicast address assignments. 
A 3G system shall be programmable to subscribe to (recognize) at least 10 multicast addresses in 
addition to its individual node address. Multicast addresses have network-wide scope. 


C.4.6 ALE. 

3G ALE provides functionality similar to second-generation ALE (2G ALE) as described in 
Appendix A, but with improved ability to link in stressed channels, to link more quickly, and to 
operate efficiently in large, data-oriented networks. 


3G ALE systems shall be capable of operation in both asynchronous and synchronous modes in 
accordance with C.5.2.4 and C.5.2.5. A system operating in synchronous mode shall recognize 
asynchronous-mode scanning calls addressed to it and respond to such calls in accordance with 
the asynchronous-mode protocol. 
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After a link is established using 3G-ALE, the system shall wait no more than a programmable 
time, (Ttraf wait Time or trafWaitTimeMcast as appropriate), for traffic setup to begin, and shall 
return to scanning if traffic setup has not begun within that time. 


C.4.6.1 System performance requirements. 
Requirements for linking probability and occupancy detection are specified in the following 
paragraphs. 


C.4.6.1.1 Linking probability. 

3G ALE systems shall meet or exceed the linking probability requirements of table C-I while 
operating in synchronous or asynchronous mode. The test procedure of A.4.2.3 shall be 
employed, with the following modifications: 


e The multipath delay settings shall be 0.5 ms for the Good channel and 2.0 ms for the 
Poor channel. 


e Units under test shall scan 3 calling channels (C = 3). 
e The requested traffic type shall be packet data. 


e =A link will be declared successful if, in response to the first Call PDU sent, the 3G-ALE 
controllers complete an individual call handshake and both tune to the traffic channel 
specified in the handshake PDU to begin traffic setup. 


Additional requirements are listed in the following paragraphs that are specific to operation in 
synchronous or asynchronous mode. 


TABLE C-I. Linking probability requirements (3 kiloHertz (kHz) signal to noise ratio 
(SNR) decibels (dB)). 


Prob Link Success Gaussian ITU-R ITU-R 
F.250-2 Good _—F.250-2 Poor 


C.4.6.1.1.1 Linking probability for synchronous operation. 
3G ALE systems operating in synchronous mode shall meet or exceed the linking probability 
requirements of table C-I. 


NOTE: Synchronous-mode systems will normally link within 4 seconds if the call is placed 


on the first channel scanned, but may defer calling until a later dwell if the current channel 
has been recorded as non-propagating. 
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C.4.6.1.1.2 Linking probability for asynchronous operation. 
3G ALE systems operating in asynchronous mode shall meet or exceed the linking probability 
requirements of table C-I. 


C.4.6.1.2 Occupancy detection. 

3G ALE systems shall detect occupied channels as specified below for synchronous or 
asynchronous operation, and shall not send ALE PDUs on channels that appear to be occupied 
without operator intervention. The probability of declaring a channel occupied when it carries 
only additive white gaussian noise (AWGN) shall be less than 1 percent. 


C.4.6.1.2.1 Occupancy detection for synchronous operation. 

3G ALE systems operating in synchronous mode shall correctly recognize that a channel is 
occupied at least as reliably as indicated in table C-II during the Listen portion of Slot 0 (see 
C.5.2.3, Synchronous dwell structure). The test procedure of A.4.2.2 shall be used. Systems 
shall also meet or exceed the requirements of table C-II for detecting calling channels in use 
while listening before calling during Slots 1 through 3. 


C.4.6.1.2.2 Occupancy detection for asynchronous operation. 

3G ALE systems operating in asynchronous mode shall meet the occupancy detection 
requirements of A.4.2.2, using the test procedure specified in A.4.2.2. Such systems shall also 
meet the 3G-ALE and 3G-HDL occupancy detection requirements of table C-II. 


TABLE C-II. Synchronous-mode occupancy detection requirements (3 kHz SNR dB). 
Waveform AWGN 3 kHz Minimum Required 
SNR (dB) Detection Probability 
2G-ALE 0 50% 
6 90% 
3G-ALE (BW0) -9 50% 
-6 95% 


3G-HDL (BW2) 30% 
70% 


0 

6 
single sideband (SSB) Voice 6 50% 
MIL-STD-188-110 or 0 30% 


STANAG 4285 or 0 30% 
6 


STANAG 4529 PSK modem 70% 


C.4.6.2 Calling channel selection. 
The 3G ALE calling protocols inherently evaluate channels during link establishment. However, 
informed selection of the initial calling channel can reduce calling overhead (in both synchronous 
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and asynchronous modes) and result in faster linking (in asynchronous mode). 3G ALE systems 
should use all available channel quality data to select the initial channel for calling: 


e Calling channel link quality measurements collected from all received PDUs. 
e Occupancy of traffic channels monitored during Slot 0 of each scanning dwell. 


e Data from prediction programs and other external sources stored in the channel quality 
data in the 3G ALE Station table (e.g., via the network management interface). 


C.4.6.3 Interoperability with 2G systems. 
A 3G ALE system shall always listen for 2G signalling when it is listening for 3G calls. 2G 
sounds shall be evaluated, and the results shall be stored for use in placing 2G calls. 


C.4.6.4 MIL-STD-188-148A functionality. 

When establishing a link while operating in MIL-STD-188-148A frequency-hopping mode, a 3G 
ALE system shall spread each PDU over multiple hops in accordance with Appendix F. Linking 
performance when linking while hopping shall meet or exceed the requirements of Appendix F. 


C.4.7 Data link protocol. 

When a link has been established for packet data transfer, using 3G-ALE or other means, the TM 
protocol in accordance with C.5.4 shall be used to coordinate use of the HDLand LDL protocols 
in accordance with C.5.5 and C.5.6 to transfer data messages. When a link has been established 
for data virtual circuit operation, the CLC protocol (C.5.7) shall be used. 


C.4.8 Automatic link maintenance. 
The Relink and Restart commands of C.5.3 shall be used to initiate changes in frequency or data 
link operating mode when such changes would result in higher performance. 


C.4.9 Network management interface. 
3G systems should provide a network management interface in accordance with Appendix D to 
facilitate interoperability with common network management systems. 


C.4.10 Order of transmission. 
Unless otherwise specified, all PDUs shall be serialized as follows: 


e Fields within a PDU shall be sent in left-to-right order. 
e Bits within fields shall be sent most-significant bit (MSB) first. 


NOTE: The MSB of each field is shown as the leftmost bit in each figure in this appendix. 


C.4.11 3G ALE data structures. 
3G systems shall implement the following data structures at the network management interface 
(if provided). 
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C.4.11.1 Station self address. 
The “self address” of each 3G ALE station table shall be an index into the station table (see 
below). 


C.4.11.2 Station table. 
The 3G ALE station table shall be capable of storing at least 128 entries. Each entry shall 
contain at least the following fields: 


e Station call sign in accordance with 2G format (up to 15 ASCII-36 characters) 
e 3G address (11 bits, including dwell group number) 


e Multicast subscription flag (indicates whether the associated address of this entry is a 
multicast to which this station listens) 


e Channels on which address is valid 


e Link quality measurements from that station on each calling and traffic channel 
including time of measurement 


e Current station status 


Entries for all network members shall be locked in the table. Other table entries shall store data 
obtained from received PDUs, with the oldest such entry replaced when new data is available and 
the table is full. 


C.4.11.3 Channel table. 

The channel table shall provide storage for at least 128 channel entries. Individual flags for each 
channel shall indicate whether that channel may be used for 3G link establishment, for 2G link 
establishment, and for traffic. Each entry shall also include transmit and receive frequencies, 
antenna selection and settings, power limits, and modulation type. 


C.4.12 Cyclic Redundancy Check (CRC) computation procedure. 

A CRC (Cyclic Redundancy Check) is a sequence of bits computed in a specific manner from a 
sequence of input bits. The CRC is concatenated with the string of input bits and the entire 
sequence is transmitted over a channel. At the receive side of the channel, the CRC is used to 
attempt to determine whether the channel caused there to be any errors in the concatenated 
sequence. The input sequence of bits is said to be covered by the CRC. A suitably chosen 
method for generating the CRC sequence can reduce the probability of undetected random 
channel errors to approximately (4) where K is the number of bits comprising the CRC. All of 
the CRCs used in the protocols defined in this Appendix shall be computed using the procedure 
defined below. 


When a CRC is to be computed from the non-CRC bits of a given PDU, the following must be 
known: 
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Uo, Ui, ... Uns the N non-CRC bits contained in the PDU, in the order in which they will 
be coded, modulated, and transmitted, so that Uo will be the first bit input to the 
PDU coding and modulation processing. 


x A K" order polynomial with binary coefficients of form: 
g polyn ry 
1+ gi*xX + g*X° fice a gK.2* xX? + gtx! + xk 


NOTE: 1. The order K of this polynomial indicates the number of bits comprising the 
CRC. 
NOTE: 2. The zero” and K" coefficients, go and gx, are equal to one. 


The following diagram indicates the operations necessary to compute the CRC. The addition 
operation pictured is binary addition (exclusive-or). The multipliers pictured represent binary 
multiplication (or binary and); specifically, each circle containing the name of one of the 
polynomial coefficients multiplies its input by the coefficient value (0 or 1) to produce its output. 


Una, Un.2, eiss99) U2, UL, Uo 


FIGURE C-4. CRC computation structure. 


The above structure is used by the transmitter to produce a CRC sequence from the N user bits 
Up through Uy.; via the following procedure: 


1. Initialize binary memory elements Co through Cx-; with 0. 


2. Apply each of the N user bits in order, starting with Up, to the binary adder at the far right 
of the diagram, and perform the other indicated binary additions and multiplications. 


3. After each of the N user bits has been applied to the indicated adder, the memory 
elements Co through Cx.; contain the CRC. 


4. The K bit CRC is read out and appended to bits Up through Uy_; of the PDU in right-to- 
left order, starting with Cx.; and finishing with Co, so that the entire PDU with CRC is 
the bit-sequence (Up, ..., Un-1, Cx-1, ..., Co), with Up being the first bit and Cp the last. 
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NOTE: The structure can be viewed as a feedback shift register with feedback connections 
corresponding to the coefficients of the polynomial: the feedback connection labeled ‘g;’ is 
present if and only if the coefficient gj is equal to one. 


C.5 DETAILED REQUIREMENTS. 


C.5.1 Constituent waveforms. 

This section defines the constituent waveforms used by the Third Generation HF Automation 
protocols. Burst waveforms are defined for the various kinds of signalling required in the 
system, so as to meet their distinctive requirements as to payload, duration, time synchronization, 
and acquisition and demodulation performance in the presence of noise, fading, and multipath. 
All of the burst waveforms use the basic 8-ary PSK serial tone modulation of an 1800 hertz (Hz) 
carrier at 2400 symbols per second that is also used in the MIL-STD-188-110 serial tone modem 
waveform. Table C-IIJ summarizes the characteristics of the waveforms and their uses within 
this standard. 


TABLE C-UI. Burst waveform characteristics. 


Form leaving code rate! 
3G-ALE PDUs 613.33 ms 26 bits 160.00 ms rate = 1/2, 4x13 block 16-ary 1/96 
1472 PSK symbols 384 PSK k=7 orthogonal 
symbols convolutional Walsh 
(no flush bits) function 
Traffic Manage- | 1.30667 seconds 48 bits rate = 1/3, 16x9 block 16-ary 1/144 
ment PDUs; 3136 PSK symbols k=9 orthogonal 
HDLacknow- convolutional Walsh 
ledgement PDUs (no flush bits) function 
HDLtraffic data | 640 + (n*400) ms n*1881 | 26.67 ms rate = 1/4, none 32 unknown/ variable: 
PDUs 1536 + (n*960) PSK bits 64 PSK k=8 16 known 1/1 to 
symbols, symbols (for | convolutional (7 1/4 
n= 3, 6, 12, or 24 equalizer flush bits) 
training) 


symbols, symbols convolutional (7 | 64x65 convol- | Walsh 1/24 
n= 64, 128, 256, or flush bits)” utional block function 
512 


LDL acknow- 640.00 ms 2 bits 4-ary 1/1920 
ledgement PDUs | 1536 PSK symbols orthogonal 

Walsh 

function 


1. Reflects Forward Error Correction (FEC) and Walsh-function coding only; does not include known data or convolutional 
encoder flush bits. 

2. In this case, the number of flush bits exceeds by one the minimum number required to flush the convolutional encoder; this 
makes the number of coded bits a multiple of four as is required for the Walsh-function modulation format. 


LDL traffic data | 373.33 + (n*13.33) ms | 8n+25 266.67 ms rate = 1/2, 24x24, 32x34, 16-ary variable: 
PDUs 32n + 896 PSK bits 640 PSK k=7 44x48, or orthogonal 1/12 to 


Other waveforms, including the MIL-STD-188-110 serial tone modem waveform, can be used to 
deliver data and digitized voice signalling on circuit links established using the 3G-ALE and TM 
protocols. 
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C.5.1.1 Service primitives. 

Table C-IV defines the service primitives exchanged between the Burst Waveform (physical 
layer) entities and the higher-layer user processes that use Burst Waveform services. Note that 
there is no requirement that implementations of the waveforms and protocols defined in this 
Appendix contain precisely these service primitives; nor are the services primitives defined 
below necessarily all of the service primitives that would be required in an implementation of 
these waveforms and protocols. 
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TABLE C-IV. Burst Waveform (BWn) service primitives. 
Primative name |_ Attribute 


BWO_Send Invoked by a user process to send a 26-bit data payload using the BWO robust 
burst signalling format 
an ordered sequence of 26 bits of data to be modulated 
and transmitted using the BWO signalling format 
Originator Connection 
Management 
(CM) 


BWO_ Receive Issued by BWO Receiver when it has received a BWO transmission. 


Parameters payload the 26 bits of payload data received in the incoming BWO 
transmission. The payload value can contain undetected 
errors due to channel noise, fading, multipath, etc.; 
however, on a perfect channel, the payload value would 
be identical to the payload parameter-value of the original 
BW0O_Send primitive at the remote station. 

BWO Receiver is active. 


BWO Pre Detect Issued by BWO Receiver when it has detected a BWO acquisition preamble. 


BWORecer [| —~=S*=~=“~*“~*S*S*S*S*“‘“~*“‘“‘“~*S*~*~<~S*S 


Preconditions | BWO Receiver is active. 


burst signalling format 


Parameters payload an ordered sequence of 48 bits of data to be modulated 
Pore | and transmitted using the BW1 signalling format 
protocol 
e ™ 
BWI Receive | 


Preconditions 


BWI Receive Issued by BW1 Receiver when it has received a BW1 transmission. 


BWI _ Send Invoked by a user process to send a 48-bit data payload using the BW1 robust 


Parameters payload the 48 bits of payload data received in the incoming BW1 
transmission. The payload value can contain undetected 
errors due to channel noise, fading, multipath, etc.; 
however, on a perfect channel, the payload value would 
be identical to the payload parameter-value of the original 
BWL Send primitive at the remote station. 


BWI Receiver is active. 
Issued by BW1 Receiver when it has detected a BW lacquisition preamble. 
BWI Receiver is active. 
BW2_Send Overview Invoked by a user process to send a sequence of data packets to a remote 
eee ee station, using the BW2 high-rate burst signalling format 
Parameters tx frame a BW2 tx frame, consisting of an ordered sequence of 


NumPkts data packets to be modulated and transmitted 
using the BW2 signalling format, where NumPkts = 3, 6, 


12, or 24. Each data packet contains an ordered sequence 
of 1881 bits of payload data. 
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TABLE C-IV. Burst Waveform (BWn) service primitives (continued). 


Primative name | Attribute 


reset boolean value; reset = TRUE indicates to the BW2 
transmitter that it should reset its Forward Transmission 
counter, FTcount. 


Preconditions | A previous signalling exchange has established the time at which transmission 
of the current BW2 burst is to start, and the time at which the receiver should 
expect it to arrive. 

If reset = FALSE, the value of NumPkts for the current invocation of 
BW2_Send (i.e., the number of data packets in the forward transmission 
frame, payload) must be equal to the value of NumPkts in the preceding 
invocation of BW2_Send. (reset = TRUE in the first invocation of 
BW2_Send for a new datagram, at which time the value of NumPkts for all 
invocations of BW2_ Send throughout the duration of the datagram transfer is 
determined.) 


BW2_Receive Issued by the BW2 Receiver when it has received a BW2 transmission. 


Parameters rx frame a BW2 rx frame containing NumRcvd indexed data 
packets, where 0 < NumRcvd < NumPkts. An indexed 
data packet contains 
e payload: a data packet containing 1881 bits of 

payload data; identical to the corresponding data 
packet in the transmitted tx frame. 
index: the position at which the indexed data packet 
occurred in the forward transmission (BW2 tx frame) 
in which it was received, where 0 < index < NumPkts. 
index = 0 indicates that the packet was in the first 
packet-slot in the forward transmission. 
Only data packets received with no errors (as indicated by 
checking the 32-bit CRC added to each packet by BW2) 
are passed to the user process in a BW2 rx frame. 
Originator | BW2Receiver | 

Preconditions | BW2 Receiver is active. 

The arrival time of the incoming BW2 burst has been estimated, based on the 


_—S— arrival time of previous received signalling from the remote station. 


swe oa Invoked by a user process to send a data packet to a remote station, using the 
ee jee low-rate burst signalling format. 


Parameters payload an ordered sequence of 537, 1049, 2073, or 4121 bits of 
data to be modulated and transmitted using the BW3 
signalling format. (Note: these payload lengths are 
chosen so as to accommodate the four possible forward 
transmission lengths of the LDL; see section C.5.5.) 


reset boolean value; reset = TRUE indicates to the BW3 
modulator that it should reset its Forward Transmission 
counter, FTcount. 

Preconditions | A previous signalling exchange has established the time at which transmission 
of the current BW3 burst is to start, and the time at which the receiver should 
expect it to arrive. 

BW3_ Receive Overview Issued by the BW3 Receiver when it has successfully received a BW3 
een transmission without errors. 
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TABLE C-IV. Burst Waveform (BWn) service primitives (continued). 


Primative name | _ Attribute 


Parameters payload 537, 1049, 2073, or 4121 bits of BW3 data demodulated 
and received without errors by the Burst Waveform 
Modem, as determined by the CRC check performed by 
the BW3 receiver; identical to the payload parameter- 
value of the original BW3_Send primitive at the remote 
station. 


BW3Reeiver | SSOSOS*~<“C~*~“~*S*~*~“—~S~S~S 


Preconditions | BW3 Receiver is active. 
The arrival time of the incoming BW3 burst has been estimated, based on the 
observed arrival time of previous received signalling from the remote station. 


BW4 Send Overview Invoked by a user process to send two bits of payload data using the BW4 
robust burst signalling format. 


Parameters payload two bits of data to be modulated and transmitted using the 
BW4 signalling format. 
[Dipoweotl | SSS 


Preconditions | A previous signalling exchange has established the time at which transmission 
of the current BW4 burst is to start, and the time at which the receiver should 
expect it to arrive. 

BW4 Receive Overview | Overview | Issued by the BW4 Receiver when it has received a BW4 transmission. 


Parameters payload two bits of BW4 data received and demodulated by the 
Burst Waveform Modem. The payload value can contain 
undetected errors due to channel noise, fading, multipath, 
etc.; however, on a perfect channel, the payload value 
would be identical to the payload parameter-value of the 
original BW4 Send primitive at the remote station. 

hoe 


BW4 Receiver 


Preconditions | BW4 Receiver is active. 
The arrival time of the incoming BW4 burst has been estimated, based on the 
observed arrival time of previous received signalling from the remote station. 


C.5.1.2 Burst waveform interleaving. 
A block interleaver is used to improve FEC performance for certain of the burst waveforms 


described below. This interleaver is based on a single interleave matrix having R rows and C 
columns, and hence accommodating up to (R * C) bits. 


The particular interleaver used in each burst waveform is defined by the values assigned to the 
following set of interleaver parameters: 
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R e Number of rows 

C e Number of columns 

irs e Row increment, stuff 

ics e Column increment, stuff 

Airs e Delta row increment, stuff. Applied only when stuff count is an integer 
multiple of the number of columns. 

Aics e Delta column increment, stuff. Applied only when stuff count is an 
integer multiple of the number of rows. 

int e Row increment, fetch 

ict e Column increment, fetch 

Airt e Delta row increment, fetch. Applied only when fetch count is an integer 
multiple of the number of columns. 

Aict e Delta column increment, fetch. Applied only when fetch count is an 


integer multiple of the number of rows. 


The parameter-values for each burst waveform are given in the sections of this document 
describing the individual burst waveforms. 


Irrespective of the particular values assigned to these parameters, each of the interleavers is 
operated in the following way. Starting with the matrix empty, (R * C) input bits are stuffed one 
by one into the matrix using the algorithm: 


initialize s (stuff count), rg, and cg to zero 


while s < (R * C) 


matrix[rg,cg] = input bit 
increment s 
if (s mod R) == 0 
Cg = (Cg + icg + Aicg) mod C 
else 
Cg = (Cg + ics) mod C 
end if 
if (s mod C) == 0 
fg = (rg + ipg + Aipg) mod R 
else 
rg = (rg + irg) mod R 
end if 
end while 
NOTE: using ‘=’ to denote assignment, and ‘ ==’ to denote the equality predicate. 


Once the matrix has been filled, the (R * C) output bits are fetched one by one from the matrix in 
interleaved order, using the algorithm: 
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initialize f (fetch count), rf, and cf to zero 
while f < (R * C) 

output bit = matrixL[r¢, ce] 

nerement f 

if (f mod R) == 0 

cf = (cf + icf + Aicf) mod C 


= 


Se, 


cf = (cf + icf) mod C 

end if 

f (f mod C) == 0 

rf = (r¢ + iff + Airf) mod R 


=e 


else 


rf = (rf + ipf) mod R 
end if 
end while 


C.5.1.3. Burst Waveform 0 (BW0O). 

Burst Waveform 0 (BW0O) is used to convey all 3G-ALE (connection management) PDUs. 
Figure C-5 summarizes the structure and timing characteristics of the BWO waveform. 
Higher layer protocols cause the generation of a BWO burst by invoking the BWO_Send 
primitive. The BWO_Send primitive has one parameter: 


e payload: the 26-bit data packet to be transmitted. 


C.5.2 describes the manner in which the user process assigns values to the payload parameter. 


T Bwi_tx 


TLC peaeea tle Data 


t#— T te eT. rls T data 


Tyce = 106.667 milliseconds: 256 PSK symbols at 2400 symbols/second 
Tpre = 160.0 milliseconds: 384 PSK symbols at 2400 symbols/second 
Tdata = 346.667 milliseconds: 832 PSK symbols at 2400 symbols/second 
Tpwi tx = total duration = 613.333 milliseconds 


FIGURE C-5. BW0O timing. 
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The description of the BWO waveform generation will proceed as follows: 


e C.5.1.3.1 and C.5.1.3.2 will discuss generation of raw tribit values for the first two 
waveform components: Gain control loop compensation and Preamble. 


NOTE: A tribit number can take on the values 0,1,...,7. 


e C5.1.3.3, C.5.1.3.4, and C.5.1.3.5 will discuss the mapping of input bits to the raw tribit 
values for the data waveform component via FEC, interleaving, and orthogonal Walsh 
symbol formation. 


e C.5.1.3.6 will discuss generation of tribit values for the pseudo noise (PN) spreading 
sequence and the combining of raw tribit values and PN spreading sequence tribit 
values. 


e C.5.1.3.7 will discuss carrier modulation using combined tribit values. 


C.5.1.3.1 TLC/AGC guard sequence. 

The TLC/AGC guard sequence portion of the BWO waveform provides an opportunity for both 
the transmitting radio’s Transmit Level Control process (TLC) and the receiving radio’s 
Automatic Gain Control process (AGC) to reach steady states before the BWO preamble appears 
at their respective inputs, minimizing the distortion to which the preamble can be subjected by 
these processes. The TLC/AGC guard sequence is a sequence of 256 pseudo-random tribit 
symbols having the values shown in table C-V. The tribit symbols are transmitted in the order 
shown in table C-V, starting at the top left and moving from left to right across each row, and 
from top to bottom through successive rows. 


TABLE C-V. TLC/AGC guard sequence symbol values. 


1, 
0, 


2,3,5,7, 7,1,0,0, 0,3,1,2, 0,1,6,2, 7,4,4,3, 2,5,4,5, 6,4,2, 2,4, 
BOY Oy 25: BoP tao) Fat AT Sobed (Oy: Uy ysis abl Ug 784 oy Os F220 


55455 6,452,550 625254 


The TLC/AGC guard sequence symbols are modulated directly as described in C.5.1.3.7, without 
undergoing PN spreading as described in C.5.1.3.6. 
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C.5.1.3.2 Acquisition preamble. 

The BW0 acquisition preamble provides an opportunity for the receiver to detect the presence of 
the waveform and to estimate various parameters for use in data demodulation. The preamble 
component of BW0 is the sequence of 384 tribit symbols shown in C-VI. The preamble symbols 
are modulated directly as described in C.5.1.3.7, without undergoing PN spreading as described 
in C.5.1.3.6. The preamble symbols are transmitted in the order shown in table C-VI, starting at 
the top left and moving from left to right across each row, and from top to bottom through 
successive rows. 


When it detects a BWO acquisition preamble, the BW0 receiver issues a BWO_Pre_Detect 
service primitive, as described in table C-IV. 


TABLE C-VI. BW0O acquisition preamble symbol values. 


C.5.1.3.3 Forward error correction. 

BW0 carries a payload of 26 protocol bits. The 26 protocol bits are encoded using the r = 1/2, 
k =7 convolutional encoder shown in figure C-6, creating 52 coded bits. A ‘tail-biting’ 
convolutional encoding approach is used as follows: 


1. Initialize the six memory cells x! .. x° of the encoder with the last six bits of the payload 
sequence, P20 .. P2s, so that cell x' contains pz» and cell x° contains pos. 


2. Shift the first bit of the payload sequence, po, into cell x°. 
3. Extract the two coded output bits bp and b;, in that order, as shown in figure C-6. 
4. Shift the next payload bit into cell x°, then extract the two coded output bits by and b;. 


5. Repeat step 4 until a total of 52 coded bits have been produced. 


No flush bits are necessary for the encoding process. 
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FIGURE C-6. Rate 1/2, constraint length 7 convolutional encoder. 


The polynomials used are: 


ae ee ee 
e bo=x +x t+x°t+x +1 


© bp =x°tx*tx*tx4+] 
where x° corresponds to the most recent encoder input bit. 
C.5.1.3.4 Interleaving. 
BWO utilizes a simple block interleaver structure which can be viewed as a 4 by 13 element 


rectangular array. See C.5.1.2 for a description of the interleaving process. The interleaver 
parameters for BWO are as follows: 


293 


MIL-STD-188-141B 
APPENDIX C 


TABLE C-VII. BW0 interleaver paramenters. 


C.5.1.3.5 Orthogonal symbol formation. 
The interleaver fetch process removes 4 coded bits at a time from the interleaver matrix. These 


four coded bits are mapped into a 16-tribit sequence using the mapping given in table C-VIII. 
Note that each of the four-bit sequences in the Coded Bits column of the table is of the form 
b3b2b,;bo, where bs is the first bit fetched from the interleaver matrix. The 16-tribit sequence thus 
obtained is repeated 4 times to obtain a 64-tribit sequence. The tribit values are placed in the 
output tribit sequence in the order in which they appear in the corresponding row of table C-VIII, 
moving from left to right across the row. 


TABLE C-VIII. Walsh modulation of coded bits to tribit sequences. 


0000 0000 
| 0404 0404 
| 0044 00 


| 000 
040 

004 
1 O44 
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This process repeats for a total of 13 iterations (one for each group of four coded bits) to produce 
832 raw tribit values. 


C.5.1.3.6 Psuedo noise (PN) spreading sequence generation and application. 

A sequence of 832 pseudo-random tribit values s; is generated by extracting 64-tribit sequences 
from table C-IX, 832/64 = 13 times. The tribit values are extracted in the order shown in 

table C-IX, starting at the top left and moving from left to right across each row, and from top to 
bottom through successive rows. The table contains 256 values; therefore, the PN spreading 
sequence is repeated every 4 blocks of 64 tribit sequences. 


TABLE C-IX. BW0 PN spreading sequence. 


Fle l 2% Oy O81 sis Of05 152. 2451 hy Labs by ToT O05 7.352355 fF 915650 
6565.05.15 354,454, 0,3 352) V4, 5545 5535415 e250, Zs ly bo 7 ¥ 2250,:0,;.6 


The 832 tribit values s; of the PN sequence are then combined with the 832 raw tribit values 7; 
produced by the orthogonal symbol formation process described in the previous section. Each 
symbol of the PN sequence s; is combined with the corresponding symbol 7; of the raw tribit 
sequence to form a channel symbol c;, by adding s; to r; modulo 8. For instance, if s; = 7, 7; = 4, 
then c; = 7 © 4 = 3, where the symbol © represents modulo-8 addition. 

The process can be summarized: 


Co Yo So 


C2303 1 2303 $2303 


where r is the vector of data raw tribit values, s is the vector of PN sequence tribit values, c is the 
resulting vector of combined tribit values, and the symbol © represents component-wise 
modulo-8 addition. 


C.5.1.3.7 Modulation. 
The sequence of channel symbols consisting of 


e the TLC/AGC guard sequence of 256 tribit symbols described by C.5.1.3.1 (on which 
no PN-spreading has been performed), followed by 
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e the acquisition preamble sequence of 384 tribit symbols described by C.5.1.3.2 (on 
which no PN-spreading has been performed), followed by 


e =the 832-length sequence of BW1 channel symbols (data symbols), PN-spread as 
described in C.5.1.3.6, 


is used to PSK modulate an 1800 Hz carrier signal at 2400 channel symbols/sec. 


See C.5.1.8 for a description of how the channel symbol values are mapped to carrier phases and 
the subsequent carrier modulation process. 


C.5.1.4 Burst Waveform | (BW1). 
Burst Waveform | (BW1) is used to convey all TM PDUs and the HDL protocol’s HDL_ACK 


PDU. Figure C-7 summarizes the structure and timing characteristics of the BW1 waveform. 
Higher layer protocols cause the generation of a BW1 waveform by invoking the BW1_ Send 
primitive. The BW1_ Send primitive has one parameter: 


e payload: the 48-bit data packet to be transmitted. 


Sections C.5.2 and C.5.3 describe the manner in which the user processes assign values to the 
payload parameter. 


T pwi_tx 


TLC een 


Kt— T i rhe Tyre rls 


Tye = 106.667 milliseconds: 256 symbols at 2400 symbols/second 
Tpre = 240.0 milliseconds: 576 symbols at 2400 symbols/second 
Taata = 960.0 milliseconds: 2304 symbols at 2400 symbols/second 
Tpw1 tx= total duration = 1.30667 seconds 


FIGURE C-7. BW1 timing. 


The description of the BW1 waveform generation will proceed as follows: 
e C.5.1.4.1 and C.5.1.4.2 will discuss generation of raw tribit values for the first two 


waveform components: Gain control loop compensation and Preamble. 
NOTE: A tribit number can take on the values 0,1,...,7. 
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e C.5.1.4.3, C.5.1.4.4, and C.5.1.4.5 will discuss the mapping of input bits to the raw tribit 
values for the data waveform component via FEC, interleaving, and orthogonal Walsh 
symbol formation. 


e C.5.1.4.6 will discuss generation of tribit values for the PN spreading sequence and the 
combining of raw tribit values and PN spreading sequence tribit values. 


e C.5.1.4.7 will discuss carrier modulation using combined tribit values. 


C.5.1.4.1 TLC/AGC guard sequence. 
The TLC/AGC guard sequence portion of the BW1 waveform provides an opportunity for both 


the transmitting radio’s Transmit Level Control process (TLC) and the receiving radio’s 
Automatic Gain Control process (AGC) to reach steady states before the BW1 preamble appears 
at their respective inputs, minimizing the distortion to which the preamble can be subjected by 
these processes. The TLC/AGC guard sequence is a sequence of 256 pseudo-random tribit 
symbols having the values shown in table C-X. The tribit symbols are transmitted in the order 
shown in table C-X, starting at the top left and moving from left to right across each row, and 
from top to bottom through successive rows. For convenience of implementation, the length of 
the TLC/AGC guard sequence (256 PSK symbols) has been chosen so as to be an integral 
multiple of the length (64 PSK symbols) of the Walsh-function modulated orthogonal symbols 
described in C.5.1.4.5. 


TABLE C-X. TLC/AGC guard sequence symbol values. 


256,156,516, 3.05. 6,051 15. 5:0'5,05:6:. 25652 15 (652.3 2,- 7 fo94- 53% 0:,253:,,5); 
25 be Dis liy Diy d's PO. TAL, 5 454,075, 25256525 25256,.35. Bi Seie7 5. 3525455: 
O41 ye 7 T5253 6:75:05. 57,035, 150 ,7,6,..2,4,052,5 5S Oats. L515, 
6:75 3:0! 2257-56 565 0,7); B42 5:250% 0574 ig 250524 15522 Bis Age (OG S525 
15650575 12565 252502529356; -040 Ly Pols dbl 7 25252505 45394 5.25, 
0,;6,7,6, 0,5,0,7, 1,7,4 2535456, 7,2,2505, 6,4,4,6;. 6,54,2,2, 655,3,4, 
2,3,5,7, 7,1,0,0, 0,3,1,2, 0,1,6,2, 7,4,4,3, 2,5,4,5, 6,4,2,5, 6,2,2,4, 
7056525 35752555 4525 54 90.705) ble 35 25 Tb 10s 7535550) Os 20:5 


The TLC/AGC guard sequence symbols are modulated directly as described in C.5.1.4.7, without 
undergoing PN spreading as described in C.5.1.4.6. 


C.5.1.4.2 Acquisition preamble. 

The BW1 acquisition preamble provides an opportunity for the receiver to detect the presence of 
the waveform and to estimate various parameters for use in data demodulation. The preamble 
component of BW1 is a sequence of 576 tribit symbols having the values shown in table C-XI. 
The preamble symbols are transmitted in the order shown in table C-XI, starting at the top left 
and moving from left to right across each row, and from top to bottom through successive rows. 
The preamble symbols are modulated directly as described in C.5.1.4.7, without undergoing PN 
spreading as described in C.5.1.4.6. 
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, the BWI receiver issues a BW1 Pre Detect 


When it detects a BW1 acquisition preamble 


service primitive, as described in table C-IV. 


TABLE C-XI. BWI acquisition preamble symbol values. 


C.5.1.4.3 Forward error correction. 


BWI carries a payload of 48 protocol bits. The 48 protocol bits are coded using the r= 1/3, k =9 


convolutional encoder shown in figure C-8, creating 144 coded bits. A ‘tail-biting’ 


convolutional encoding approach is used as follows: 


1. Initialize the eight memory cells x' .. x° of the encoder with the last eight bits of the 
payload sequence, po .. paz, SO that cell x' contains pao and cell x* contains pz. 


8 


2. Shift the first bit of the payload sequence, po, into cell x”. 


3. Extract the first three coded output bits bitouto, bitout,, and bitout,, in that order, as 


shown in figure C-8. 


4. Shift the next payload bit into cell x*, then extract the three coded output bits bitouto, 


bitout,, and bitouty. 


5. Repeat step 4 until a total of 144 coded bits have been produced. 
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No flush bits are necessary for the encoding process. The polynomials used are: 


e Bitouty = x® XEX +X +1 


e Bitout, = x°+x Xo+X +x +1 


: 8,6, 5,3, 2, 1 
e = Bitout. = x°+x° +x +xK°4x*+x "4 


where x* corresponds to the most recent encoder input bit. 
The order of output to the interleaving process is Bitouty then Bitout, then Bitouto. 


> bitout, 


bitout, 


bitin ——~——|_ x8 | x? | x6 x° x4 | x8 | x2 x! 1 


> bitout, 


FIGURE C-8. Rate 1/3, constraint length 9 convolutional encoder. 


C.5.1.4.4 Interleaving. 
See C.5.1.2 for a description of the interleaving process. The interleaver parameters for BW1 are 
as follows: 
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TABLE C-XII. Interleaver parameters for BW1. 


See C.5.1.2 for a complete description of the block interleaving process used by the various burst 
waveforms. 


C.5.1.4.5 Orthogonal symbol formation. 
The interleaver fetch process removes 4 coded bits at a time from the interleaver matrix. These 4 


coded bits are mapped into a 16-tribit sequence using the mapping given in table C-VIII. Note 
that each of the four-bit sequences in the Coded Bits column of the table is of the form b3b2b;bo, 
where bs is the first bit fetched from the interleaver matrix. The tribit values are placed in the 
output tribit sequence in the order in which they appear in the corresponding row of table C-VIII, 
moving from left to right across the row. The 16-tribit sequence thus obtained is repeated 4 
times to obtain a 64-tribit sequence. This process repeats for a total of 36 iterations to produce 
2304 raw tribit values. 


C.5.1.4.6 PN spreading sequence generation and application. 
A sequence of 2304 pseudo-random tribit values s; is generated by repeating the 256-tribit 


sequence presented in table C-XIII, 2304 / 256 =9 times. The tribit values are used in the order 
shown in table C-XIII, starting at the top left and moving from left to right across each row, and 
from top to bottom through successive rows. 
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TABLE C-XIII. BW1 PN spreading sequence. 


O24 oo Babyy by tO yd Oy Se hes, Sy Oe OU heb h 2s Ose Any. ee aa Tl, 
SDs Oe Paces. Misgoady Files ol oOo hal BOG gO) 0x57 0605.0:,05 
Oyo O pee 2h 75 62a eto Seer ly 2, Oy Os he oA e eds Dile7535. Of Too: 
2,2,6,2, 7,6,5,2, 4,6,5,4, 7,2,5,1, 0,0,7,7, 3,5,4,2, 1,4,2,7, 0,3,4,0, 
0,0,7,7, 3,5,4,2, 1,4,2,7, 0,3,4,0, 1,0,5,2, 6,0,3,5, 1,0,5,1, 5,2,5,6, 
Bertiete Tee eee0y lyse Oy Ape iiees: TA Sue Od ede. kabel ge Delgo As 
Tele ls 2s Sebed slg OpO glace eA pled yl Oy Oe Tol wo O er Feed sO ye Tad gOS 
Gp O20 pda: Set ghee Oye 2 AoA egal Me Le be le i bats e700: 


The 2304 tribit values s; of the PN sequence are then combined with the 2304 raw tribit values 7; 
produced by the orthogonal symbol formation process described in the previous section. Each 
symbol of the PN sequence s; is combined with the corresponding symbol 7; of the raw tribit 
sequence to form a channel symbol c;, by adding s; to r; modulo 8. For instance, if s; = 7, 7; = 4, 
then c; = 7 © 4 = 3, where the symbol © represents modulo-8 addition. 

The process can be summarized: 


C2303 1 2303 $2303 


where r is the vector of data raw tribit values, s is the vector of PN sequence tribit values, c is the 
resulting vector of combined tribit values, and the symbol © represents component-wise 
modulo-8 addition. 


C.5.1.4.7 Modulation. 
The sequence of channel symbols consisting of 


e the TLC/AGC guard sequence of 256 tribit symbols described by C.5.1.4.1 (on which 
no PN-spreading has been performed), followed by 


e the acquisition preamble sequence of 576 tribit symbols described by C.5.1.4.2 (on 
which no PN-spreading has been performed), followed by 


e = the 2304-length sequence of BW1 channel symbols (data symbols), PN-spread as 
described in C.5.1.4.6, 
is used to PSK modulate an 1800 Hz carrier signal at 2400 channel symbols/sec. 
See C.5.1.8 for a description of how the channel symbol values are mapped to carrier phases and 
the subsequent carrier modulation process. 


C.5.1.5 Burst Waveform 2 (BW2). 
Burst Waveform 2 (BW2) is used for transfers of traffic data by the HDL protocol. Figure C-9 


summarizes the structure and timing characteristics of the BW2 waveform. 
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BW? is used to transmit a sequence of data packets from a transmitting station to a receiving 
station, where a data packet is defined as a fixed-length sequence of precisely 1913 data bits. 

The HDL protocol process (described in C.5.2) causes BW2 to modulate a Forward Transmission 
containing a sequence of data packets by invoking the BW2_Send primitive. The BW2_ Send 
primitive has two parameters: 


e payload: a sequence of NumPKTs data packets, where NumPKTs = 3, 6, 12, or 24; and 


e reset: a boolean parameter which is set to TRUE by the HDL protocol for the first 
Forward Transmission performed in delivering a datagram, and set to FALSE at all 
other times. reset = TRUE causes counters used in BW2’s FEC encoding and PN 
spreading processes to be reinitialized. 


C.5.2 describes the manner in which the HDL protocol determines the values assigned to these 
parameters. 


The total duration of the Forward Transmission phase of the HDL protocol is 0.64 + (0.40 * 
NumPKTs) seconds, and includes a constant-length portion and a variable-length portion. The 
constant-length portion has a fixed duration of 0.64 seconds (Trorwarp - Tpata), which includes: 


e aPreTxProcessing interval of 293.33 ms (704 PSK symbol times, at 2400 symbols per 
second), in which no waveform is transmitted or received 


e aPostTxProcessing interval of 220 ms (528 PSK symbol times, at 2400 symbols per 
second), in which no waveform is transmitted or received 


e aTLC/AGC guard sequence of 240 PSK symbols, with a duration of 100 ms (Tr) 


e aBW2 acquisition preamble sequence of 64 PSK symbols, with a duration of 26.67 ms 
(Tpre): 
The variable-length portion has a duration (Tpara) of 400 * NumPKTs milliseconds (equal to 
960 * NumPKTs PSK symbol times). 


The BW2 modulation process uses a count variable, FTcount, to keep track of how many 
Forward Transmissions have occurred in transmitting the current datagram. At the start of each 
Forward Transmission, FTcount is initialized to zero if and only if the reset parameter of the 
current invocation of BW2_ Send is TRUE. At the end of each Forward Transmission, FTcount 
is incremented. The value of FTcount is used in FEC encoding (as described in C.5.1.5.5), in 
rotating the modulation symbols containing FEC-coded data (as described in C.5.1.5.8), and in 
generating the spreading symbol sequence used to PN-spread the BW2 gray-coded modulation 
symbols (as described in C.5.1.5.8). 


The subsections of this describe the manner in which the values of the symbols in the TLC/AGC 
guard sequence, the preamble sequence, and the variable-length data portion of each Forward 
Transmission are determined, and then describe the manner in which the resulting symbol 
sequence is PN-spread and modulated. 
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Tric ——__ T preamble 


— 


EDataPKTo EDataPKT, EDataPKT»2 EDataPKT3 


T unknown T known 
pe 


Tknown = 16 8-PSK symbols at 2400 symbols/sec = 6.67 ms 
Tunknown = 32 8-PSK symbols at 2400 symbols/sec = 13.33 ms 
epee = 20.0 ms 

Tepatapktr = 20 * 20.0 ms = 400 ms 

Tpata = NumPKTs * 400 ms 

Tpreamble = 64 8-PSK symbols at 2400 symbols/sec = 26.67 ms 
Trice = 240 8-PSK symbols at 2400 symbols/sec = 100.00 ms 
Trx 126.67 + (NumPKTs * 400) ms 

Tposttx = 220 ms 

Tprtrx = 293.33 ms 

Trorward = 0.64 + (NumPKTs * 0.40) seconds 


FIGURE C-9. BW2 waveform structure and timing characteristics. 
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C.5.1.5.1 TLC/AGC guard sequence. 

The TLC/AGC guard sequence portion of the BW2 waveform provides an opportunity for both 
the transmitting radio’s Transmit Level Control process (TLC) and the receiving radio’s 
Automatic Gain Control process (AGC) to reach steady states before the BW2 preamble appears 
at their respective inputs, minimizing the distortion to which the preamble can be subjected by 
these processes. The BW2 TLC/AGC guard sequence is composed of the first 240 of the 
pseudo-random tribit symbol values shown in table C-X. The tribit symbols are transmitted in 
the order shown in table C-X, starting at the top left and moving from left to right across each 
row, and from top to bottom through successive rows. 


For convenience of implementation, the length of the TLC/AGC guard sequence (240 PSK 
symbols) has been chosen so as to be an integral multiple of the length of an unknown/known 
symbol frame as described in C.5.1.5.7. 


The TLC/AGC guard sequence symbols are modulated directly as described in C.5.1.5.9, without 
undergoing PN spreading as described in C.5.1.5.8. 


C.5.1.5.2 Acquisition preamble. 

The BW2 acquisition preamble is a sequence of 64 tribit symbols all having values of zero (000). 
The BW2 acquisition preamble symbols undergo PN spreading as described in C.5.1.5.8; the PN- 
spread preamble symbols are then modulated as described in C.5.1.5.9. 


C.5.1.5.3 CRC computation. 

A 32-bit Cyclic Redundancy Check (CRC) value is computed across the 1881 payload data bits 
in each data packet, and is then appended to the data packet. The generator polynomial used in 
computing the CRC is: 


Gee Caer oP Guero Gale Cia Cake Gan ap Gar a Carey Carey Gaiae Ga ae Ga om 


Other details of the CRC computation procedure are as defined in C.4.1. 


C.5.1.5.4 Data packet extension. 


TeEpataPkT 
Data Packet (1881 bits) CRC (32 bits) Encoder Flush (7 bits) 


Total Transmitted bits per EDataPKT = 1920 
Tepatapkt = 20 * Trrame = 20 * 20.0 ms = 400 ms 
Note: diagram is not drawn to scale. 


FIGURE C-10. Data packet extension with encoder flush bits. 
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As is shown in figure C-10, seven encoder flush bits with values of zero are appended to the 

1913 payload and CRC bits of each data packet to produce an extended data packet, known 
henceforth as an ‘EDataPkt’ (i.e., an “Extended Data Packet”). Note that the further processing 
(FEC, symbol formation, and frame formation) of each EDataPKT is not affected by the presence 
of the CRC and flush bits in the EDataPKT; in these processes, each EDataPKT is treated as an 
arbitrary sequence of 1920 bits. As described below, each 1920-bit EDataPKT is transformed 
into 20 frames of 48 PSK symbols each. Each of the 32 known 8-PSK symbols in a frame carries 
three data bits, so that each frame carries 96 of the 1920 bits in an EDataPKT. 


C.5.1.5.5 Forward error correction. 

The 1920 bits in each EDataPkt are convolutionally encoded using the rate 1/4, constraint length 
8, non-systematic convolutional encoder shown in figure C-11. The encoder produces 4 encoded 
bits: Bitouto, Bitout,, Bitout2, and Bitouts, for each single input bit. As each EDataPkt is 
encoded, the coded bits from each of the four coded bit streams are accumulated into a block of 
1920 coded bits. This produces a total of four Encoded Blocks of 1920 bits each (EBlko through 
EBIk3, where each EBIk; is composed solely of output bits from Bitout,.). Only one of the four 
Encoded Blocks resulting from the encoding of each EDataPkt is transmitted in each Forward 
Transmission. Which of the four Encoded Blocks is transmitted is determined by the value of 
the BW2 modulation process’s FTcount variable: the Encoded Block transmitted is EBIk, 
(containing coded data bits from Bitout,), where n = FTcount mod 4. For instance, the sixth 
Forward Transmission of a datagram contains EBlk; (since FTcount = 5 and 5 mod 4 = 1) for 
every EDataPkt in the Forward Transmission. Each successive retransmission of a EDataPkt 
contains a different Encoded Block derived from the EDataPkt contents, providing the decoder at 
the remote station with additional information as to the contents of the EDataPkt. 
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Bitout , 


Bitout , 


Bitouts 


The generator polynomials corresponding to the four shift registers shown here are respectively (from top to bottom): 
1. Bitouty: X7 + X4+X3 +X? +1 
2. Bitout,: X7 + X5 + X4 + X3 + X2 +14 
3. Bitout,: X7 + X6+ X3+X14+1 
4. Bitouts: X7 + X® + X5+ X3 + X2 + X1 +1, 


where x7 corresponds to the bit most recently input to the encoder. 


FIGURE C-11. Rate 1/4, constraint length 8 convolutional encoder. 


The seven zeroes in the Encoder Flush field at the end of each EDataPkt return the convolutional 
encoder to its initial (all-zero) state before it starts to encode the contents of the next EDataPkt. 


C.5.1.5.6 Modulation Symbol formation. 

Once the NumPKTs encoded blocks for each forward transmission have been produced, the 
contents of the encoded blocks are formed into three-bit modulation symbols. Each modulation 
symbol is formed by taking three bits one at a time from the current Encoded Block, starting with 
the first bit of the first Encoded Block, and shifting them successively into the modulation 
symbol’s least significant bit-position (so that the first bit of the three is eventually placed in the 
most significant bit-position). This continues until 1920/3 = 640 modulation symbols have been 
formed for each Encoded Block. 
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The modulation symbols for all Encoded Blocks are then rotated toward the least significant bit- 
position (so that M2MiMop becomes MoM2Mj), FT count mod 3 times. This causes each 
successive transmission of an Encoded Block to have its data contents mapped onto different 
modulation symbol values. After this rotation has been performed, the rotated modulation 
symbols are gray-coded as shown in table C-XIV, yielding a sequence of gray-coded modulation 
symbols. 

TABLE C-XIV. Gray coding table. 


Input Data Output Data 
(Modulation Symbol) (Gray-Coded Modulation Symbol) 
000 000 
001 001 
010 011 
O11 010 
100 111 
101 110 
110 100 
111 101 


C.5.1.5.7 Frame formation. 

Once the NumPKTs Encoded Blocks have been formed into modulation symbols, rotated, and 
gray-coded, the resulting gray-coded modulation symbols are formed into Frames. Each Frame 
(as shown on figure C-9) is formed by taking the next 32 consecutive gray-coded modulation 
symbols (known as “unknown symbols” because they contain coded payload data not known a 
priori) from the sequence produced as described in the previous section, and appending to them 
16 known symbols having symbol values equal to zero (000). The 640 gray-coded modulation 
symbols for each Encoded Block are incorporated into the unknown sections of 20 Frames (since 
640/32 = 20). For a Forward Transmission containing NumPKTs EDataPkts, there will therefore 
be (20 * NumPKTs) Frames, each containing 32 gray-coded modulation symbols (unknown 
symbols) derived from encoded payload data, followed by 16 known symbols having values of 
zero. 


C.5.1.5.8 PN spreading sequence generation and application. 

The length 2'°-1 Maximum-Length Sequence Generator shown in figure C-12 is used to PN- 
spread the sequence of modulation symbols (tribits) consisting of the 64 symbols of the BW2 
acquisition preamble described by C.5.1.5.2, followed by the (960 * NumPKTs) gray-coded 
modulation symbols generated as described in sections C.5.1.5.3 through C.5.1.5.7. 
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B,, B,, By used as outputs to generate PN Modulation Sequence 


1 
FIGURE C-12. 2 . - 1 maximum-length sequence generator. 


The Forward Transmission count variable FTcount (described in C.5.1.5) is used in initializing 
the state of the sequence generator: at the start of each Forward Transmission, the state of the 
generator is initialized to (OxAB91 + FTcount) mod 0x 10000. 


The outputs of the sequence generator are used to PN-spread the modulation symbols as follows: 


1. For each input symbol (preamble symbol or gray-coded modulation symbol), a three-bit 
spreading symbol is formed by cycling the PN generator three times, and then taking the 
three least significant bits By, B,, and Bo (as shown in figure C-12) from the shift register, 
with By becoming the most significant bit of the spreading symbol. 


2. The spreading symbol is then summed modulo 8 with the input symbol to form a three- 
bit channel symbol. 


This is performed for each of the 64 preamble symbols and each of the (960 * NumPKTs) gray- 
coded modulation symbols. Note that since all of the preamble symbols and the known 
modulation symbols were filled with zero values (000), and the Gray-coding of zero yields zero, 
the preamble channel symbols and the known channel symbols actually contain the spreading 
symbols. 


C.5.1.5.9 Modulation. 
The sequence of channel symbols consisting of: 
e the TLC/AGC guard sequence described by C.5.1.5.1 (on which no gray-coding or PN- 
spreading has been performed), followed by 


e the 64-length sequence of BW2 acquisition preamble symbols described by C.5.1.5.2, 
PN-spread as described in C.5.1.5.8; followed by 


e the (960 * NumPKTs) gray-coded modulation symbols generated as described in 
C.5.1.5.3 through C.5.1.5.7, and PN-spread as described in C.5.1.5.8, 


is used to PSK modulate an 1800 Hz carrier signal at 2400 channel symbols/sec. 
See C.5.1.8 for a description of how the channel symbol values are mapped to carrier phases and 
the subsequent carrier modulation process. 
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C.5.1.6 Burst Waveform 3 (BW3). 
Burst Waveform 3 (BW3) is used for transfers of traffic data by the LDL protocol. Figure C-13 
summarizes the structure and timing characteristics of the BW3 waveform. 


BW3 is used to transmit a single data packet from a transmitting station to a receiving station, 
where a data packet is defined as a fixed-length sequence of 537, 1049, 2073, or 4121 bits. The 
number of bits in a BW3 data packet is of the form 8n+25, where n = 64, 128, 256, or 512. The 
value ‘n’ used throughout this section refers to the number of payload data bytes (or octets) 
carried by each LDL protocol forward transmission; the additional 25 bits of payload in each 
BW3 transmission are LDL overhead. BW3 is used only to deliver forward transmissions of the 
LDL protocol described in C.5.5. 


The LDL protocol process causes the generation of a BW3 waveform by invoking the 
BW3_Send primitive. The BW3_Send primitive has two parameters: 


e payload: the (8n+25)-bit data packet to be transmitted; and 


e reset: a boolean parameter which is set to TRUE by the LDL protocol for the first 
Forward Transmission performed in delivering a datagram, and set to FALSE at all 
other times. eset = TRUE causes the Forward Transmission counter FTcount used in 
BW3’s FEC encoding process to be reinitialized. 


C.5.5 describes the manner in which the LDL protocol determines the values assigned to these 
parameters. 


| T Bw 3_tx — 


Pream ble 


>|~< T a >| 


al T > 
T, = 266.67 milliseconds: 640 PSK symbols at 2400 symbols/second 
Tg = 106.67 + (n*13.33) milliseconds: 32n + 256 PSK symbols at 2400 symbols/second, 
where 


n= 64, 128, 256, or 512. 
Tpw3 tx = 373.33 + (n*13.33) milliseconds; i.e., approximately 1.227, 2.080, 3.787, or 7.200 
seconds 


FIGURE C-13. BW3 timing. 


The BW3 modulation process maintains a count variable, FTcount, to keep track of how many 
forward transmissions have occurred in transmitting the current datagram. FTcount is initialized 
to zero upon reception of a BW3_Send PDU having its reset parameter set to TRUE. At the end 
of each BW3 forward transmission, FTcount is incremented by one. The value of FTcount is 
used in FEC encoding as described in C.5.1.6.3. 


309 


MIL-STD-188-141B 
APPENDIX C 


The description of BW3 waveform generation will proceed as follows: 


e Section C.5.1.6.1 will discuss generation of tribit values for the Preamble waveform 
component. 


e Sections C.5.1.6.2, C.5.1.6.3, C.5.1.6.4, and C.5.1.6.5 will discuss the mapping of input 
bits to raw tribit values for the data waveform component via CRC computation, FEC, 
interleaving, and orthogonal Walsh symbol formation. 


e Section C.5.1.6.6 will discuss the generation of tribit values for the PN spreading 
sequence and the combining of these PN spreading sequence tribit values with the raw 
tribit values for the data waveform component. 


e Section C.5.1.6.8 will discuss carrier modulation using the preamble and PN-spread 
data tribit values. 


C.5.1.6.1 Preamble. 

This portion of the burst waveform provides an opportunity for both the transmitting radio’s 
Transmit Level Control process (TLC) and the receiving radio’s Automatic Gain Control process 
(AGC) to reach steady states, and provides an opportunity for the receiver to detect the presence 
of the waveform and to estimate various channel parameters for use in data demodulation. The 
preamble component of BW3 is a sequence of 640 tribit values having the values shown in table 
C-XV. The preamble symbols are transmitted in the order shown in table C-XV, starting at the 
top left and moving from left to right across each row, and from top to bottom through successive 
rows. The preamble symbols are modulated directly as described in section C.5.1.4.7, without 
undergoing PN spreading as described in section C.5.1.6.6. 


A TLC/AGC guard sequence is not provided as an explicit part of the BW3 waveform, since the 
correlation-based receive processing of the BW3 waveform is relatively insensitive to such signal 
perturbations as are likely to be introduced by the TLC and AGC processes. The duration of the 
BW3 preamble includes sufficient time for preamble acquisition to be performed after the TLC 
and AGC processes have settled. 
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TABLE C-XV. BW3 preamble symbol values. 


C.5.1.6.2 CRC computation. 


A 32-bit Cyclic Redundancy Check (CRC) value is computed across the payload data bits in the 
data packet, and is then appended to the data packet. The generator polynomial used in 


computing the CRC is: 
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Other details of the CRC computation procedure are as defined in C.4.1. 


C.5.1.6.3 Forward error correction. 


7 flush bits having the value 0 are appended to the (8n+57) bits of the data packet with CRC to 


ensure that the encoder is in the all-zero state upon encoding the last flush bit. The data and CRC 


7 convolutional encoder shown in C-14. 


bits and the 7 flush bits are coded using the r = 1/2, k 


NOTE 1. Since BW3 uses a k=7 convolutional code, only 6 bits are literally needed to flush 


the encoder. The seventh ‘flush bit’ is added purely for convenience -- to make the number 


of coded bits per BW3 transmission a multiple of four, so that each group of four bits can 


then be mapped to an orthogonal symbol as described below. 


NOTE 2. The generator polynomials corresponding to Bitout0 and Bitout] are: 


Bitouto: X°HX44+X3+X41 
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e = Bitout,;: X°+X°+X44X4+1 


e where X° corresponds to the most recent input bit. 


> Bitouty 


FIGURE C-14. BW3 rate 1/2, k=7 convolutional encoder. 


This encoder produces two encoded bits, Bitouty and Bitout,, for each single input bit. Encoding 
an entire sequence of (8n+57) data and CRC bits followed by 7 flush bits results in two encoded 
blocks of (8n+64) coded bits each, EBlkp and EBIk;, where each EBlk, is made up solely of 
output bits from Bitout,. In each forward transmission, only coded bits from EBlkezeount mod 2) ate 
passed forward to the interleaving process, where FTcount is the forward transmission count 
variable described in C.5.1.6; the encoded bits from the other encoded block are retained to 
possibly be transmitted in one or more subsequent forward transmissions. For instance, the 
fourth forward transmission of a data packet contains the coded bits from EBIk; (since 

FTcount = 3 and 3 mod 2 = 1). 


C.5.1.6.4 Interleaving. 


See C.5.1.2 for a description of the interleaving process. The interleaver parameters for BW3 
depend on the value n (which determines the BW3 payload size), as shown in table C-XVI. 
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TABLE C-XVI. Interleaver parameters for BW3. 


| R | 24 | 32 | 44 | 64 | 
| C_ | 24 | 34 | 48 | 65 | 


(oie ots oe [ae 


C.5.1.6.5 Orthogonal symbol formation. 

The interleaver fetch process removes 4 coded bits at a time from the interleaver matrix. These 4 
coded bits are mapped into a 16-tribit sequence using the mapping given in tabel C-VIII. Note 
that each of the four-bit sequences in the Coded Bits column of the table is of the form b3b2b;bo, 
where bs is the first bit fetched from the interleaver matrix. The tribit values are placed in the 
output tribit sequence in the order in which they appear in the corresponding row of table C-VIII, 
moving from left to right across the row. This process repeats for a total of 2n+16 iterations to 
produce the 32n+256 raw tribit values of the data portion of BW3. 


C.5.1.6.6. PN spreading sequence generation and application. 

A sequence of 32n+896 pseudo-random tribit values s; is generated by repeating the 32-tribit 
sequence presented in table C-X VII, (32n+256) / 32 =n+8 times. The tribit values are used in 
the order shown in table C-XVII, starting at the top left and moving from left to right across each 
row, and from top to bottom through successive rows. 


TABLE C-XVII. BW3 PN spreading sequence. 


(=> )e =>) 
SO: 
Ww Po 


oo 
oo 
a) 


OR 
NO 
NS 
OR 
NO 
OR 
Wo 
Lo 
SR 
nN 


The 32n+256 tribit values s; of the PN sequence are then combined with the 32n+256 raw tribit 
values r; produced by the orthogonal symbol formation process described in the preceding 
section. Each symbol of the PN sequence s; is combined with the corresponding symbol 7; of the 
raw tribit (data) sequence to form a channel symbol c;, by adding s; to 7; modulo 8. For instance, 
if s;= 7, 7; =4, then c; = 7 © 4 = 3, where the symbol © represents modulo-8 addition. 
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The process can be summarized: 
Co Vdo So 
sis @}: 
C32n + 255 Vd 32n + 255 S32n + 255 


where rg is the vector of data raw tribit values, s is the vector of PN sequence tribit values, c is 
the resulting vector of combined tribit values, and the symbol © represents component-wise 
modulo-8 addition. 


C.5.1.6.7 Modulation. 
The sequence of channel symbols consisting of 


e the preamble sequence of 640 tribit symbols described by section C.5.1.6.1 (on which 
no PN-spreading has been performed), followed by 


e the sequence of (32n+256) BW3 channel symbols (data symbols), PN-spread as 
described in section C.5.1.6.6, 
is used to PSK modulate an 1800 Hz carrier signal at 2400 Channel Symbols/sec. See section 
C.5.1.8 for a description of how combined tribit values are mapped to carrier phases and the 
subsequent carrier modulation process. 


C.5.1.7 Burst Waveform 4 (BW4). 
Burst Waveform 4 (BW4) is used to convey the LDL protocol’s LDL_ACK PDU. Figure C-15 


summarizes the structure and timing characteristics of the BW4 waveform. 
A user process (the LDL protocol) causes the generation of a BW4 waveform by issuing a 
BW4 Send primitive. The BW4 Send primitive has one parameter: 


e payload: the two bits of payload data to be transmitted. 


C.5.5 describes the manner in which values are assigned to the payload parameter. 


Tt = 106.666 milliseconds: 256 PSK symbols at 2400 symbols/second 
Tdata = 533.333 milliseconds: 1280 PSK symbols at 2400 symbols/second 
Tawa tx = 640.0 milliseconds 


FIGURE C-15. BW4 timing. 
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The description of the BW4 waveform generation will proceed as follows: 
e C.5.1.7.1 will discuss generation of raw tribit values for the TLC/AGC guard sequence 


e = C.5.1.7.2 will discuss the mapping of input bits to the raw tribit values for the Data 
waveform component. 


e C.5.1.7.3 will discuss the combining of raw tribit values with the PN spreading 
sequence tribit values. 


e C.5.1.7.4 will discuss carrier modulation using combined tribit values. 


C.5.1.7.1 TLC/AGC guard sequence. 

The TLC/AGC guard sequence portion of the BW4 waveform provides an opportunity for both 
the transmitting radio’s Transmit Level Control process (TLC) and the receiving radio’s 
Automatic Gain Control process (AGC) to reach steady states before the BW4 preamble appears 
at their respective inputs, minimizing the distortion to which the preamble can be subjected by 
these processes. The TLC/AGC guard sequence is a sequence of 256 pseudo-random tribit 
symbols having the values shown in table C-X. The tribit symbols are transmitted in the order 
shown in table C-X, starting at the top left and moving from left to right across each row, and 
from top to bottom through successive rows. 


The TLC/AGC guard sequence symbols are modulated directly as described in C.5.1.7.4, without 
undergoing PN spreading as described in C.5.1.7.3. 


C.5.1.7.2 Orthogonal symbol formation. 

BW4 carries a payload of two protocol bits. The two protocol bits are mapped into a 16-tribit 
sequence using the mapping given in table C-X VIII. Note that each of the two-bit sequences in 
the Payload Bits column of the table is of the form b,bo, where b, is the first payload bit. The 
tribit values are placed in the output tribit sequence in the order in which they appear in the 
corresponding row of table C-X VIII, moving from left to right across the row. The 16-tribit 
sequence thus obtained is repeated 80 times to produce 1280 tribit values. 


TABLE C-XVIII. Walsh modulation of BW4 payload bits to tribit sequences. 


Payload Bits Tribit Sequence 
(shown as b;bo) 


00 0000 0000 


01 0404 
10 14 0044 
11 10 04 


C.5.1.7.3 PN spreading sequence generation and application. 
The BW4 PN spreading sequence is the sequence of 1280 pseudo-random tribit values s; shown 


in table C-XIX. The tribit values are used in the order shown in table C-XIX, starting at the top 
left and moving from left to right across each row, and from top to bottom through successive 
rOWS. 
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TABLE C-XIX. BW4 PN spreading sequence. 


The 1280 tribit values s; of the PN sequence are combined with the 1280 raw tribit values 7; 


produced by the orthogonal symbol formation process described in the previous section. Each 
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symbol of the PN sequence s; is combined with the corresponding symbol 7; of the raw tribit 


sequence to form a channel symbol c;, by adding s; to r; modulo 8. For instance, if s; = 7, 7; = 4, 
then c; = 7 © 4 = 3, where the symbol © represents modulo-8 addition. 


The process can be summarized: 


C1279 11279 $1279 


where + is the vector of data raw tribit values, s is the vector of PN sequence tribit values, c is the 
resulting vector of combined tribit values, and the symbol © represents component-wise 
modulo-8 addition. 


C.5.1.7.4 Modulation. 
The sequence of channel symbols consisting of: 


e the TLC/AGC guard sequence of 256 tribit symbols described by C.5.1.7.1 (on which 
no PN-spreading has been performed), followed by 


e the 1280-length sequence of BW4 channel symbols (data symbols), PN-spread as 
described in C.5.1.7.3, 


is used to PSK modulate an 1800 Hz carrier signal at 2400 channel symbols/sec. 
See C.5.1.8 for a description of how combined tribit values are mapped to carrier phases and the 
subsequent carrier modulation process. 


C.5.1.8 Burst waveform modulation. 

The burst waveform descriptions have thus far only discussed the mapping of protocol bits to 
tribit values. This section will describe the process by which the tribit values are used to create 
the transmitted signal. 


The transmitted signal consists of a 8-ary phase-shift-keyed 1800Hz single-tone carrier 
modulated at a constant 2400 symbols per second. The phase shift of the signal relative to that of 
the unmodulated carrier is a function of the tribit values as given in the tribit-value-to-carrier- 
phase mapping of table C-XX: 
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TABLE C-XX. 8-ary PSK signal space. 


Tribit Phase ae ane ial 
= = 
ae 


The transmitted waveform is generated as illustrated in C-16. The tribit values are converted to 
the complex 8-PSK resulting in separate In-Phase [I] and Quadrature [Q] waveforms as given in 
C-XX. These waveforms are interpolated and independently filtered by equivalent low pass 
filters to provide spectral containment and image rejection. Finally, the interpolated and filtered 
In-phase and Quadrature waveforms are used to modulate the 1800 Hz sub-carrier. The accuracy 
of the clock linked with the generation of the sub-carrier frequency is 1 part in 10°. 


2400 
symbols/ 
second 


Cos 1800Hz 


-Sin 1800Hz 


FIGURE C-16. Carrier modulation. 


C.5.2 3G-ALE protocol definition. 
3G-ALE shall be implemented as defined in the following paragraphs. 
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C.5.2.1 3G-ALE service primitives. 

Table C-XXI describes an example set of service primitives exchanged between the 3G-ALE 
entity and a user process at the 3G-ALE entity upper interface. Note that there is no requirement 
that implementations of 3G-ALE contain precisely these service primitives; nor are the service 
primitives defined below necessarily all of the service primitives that would be required in an 
implementation of this protocol. 


TABLE C-XXI. 3G-ALE service primitives. 


Attribute Values Description 


ILE Link Req Overview LE_Link Req: issued by ALE user process (usually connection manager) to request 
establishment of a link 


Parameters destAddr 11-bit 3G address of the station to be called 
callType one of INDIVIDUAL, UNICAST, MULTICAST, BROADCAST 


trafType Identifies the type of traffic for which the link is requested; one of: Packet Data, 
Modem Circuit (for HF data modems only), Voice Circuit (for analog voice or non- 
HF modems), High-Quality Circuit 


pri Priority of the traffic for which the link is requested; one of Highest, High, Routine, 
Low 


callChan Optional calling channel number (for override) 
trafChan Optional traffic channel number (for override) 
Originator user process 
Preconditions none 


ILE Link Ind Overview LE _ Link Ind: issued by ALE process to indicate the establishment of link as 
responder 


Parameters addr 11-bit 3G address of the station or multicast to which link has been established 
callType Identifies the type of link that has been established; same values as above 

Originator ALE entity 
Preconditions none 

ILE Link Confirm Overview LE_ Link Confirm: issued by ALE process to indicate establishment of link as caller 
Parameters addr 11-bit 3G address of the station or multicast to which link has been established 
Originator ALE entity 
Preconditions link has been requested or established 

ILE Status Ind Overview LE Status Ind: issued by ALE process to indicate its current status 
Parameters status Current ALE status; one of: SCANNING, CALLING, LINKED 
Originator ALE entity 


Preconditions 


ILE Link Det_Ind Overview LE Link Det_Ind: issued by ALE process to report detection of the establishment or 
termination of a link between remote stations 


Parameters status One of LINKED, AVAILABLE 
trafChan Traffic channel used by link 
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TABLE C-XXI. 3G-ALE service primitives (continued). 


Attribute 


Originator 
Preconditions 


Overview 


Parameters 


Originator 
Preconditions 


Overview 


Parameters 
Originator 
Preconditions 


Overview 


Parameters 


Originator 


Preconditions 


C.5.2.2 3G-ALE PDUs. 
The link establishment protocol data units (LE-PDUs) are shown in figure C-17. Unused 
encodings are reserved, and shall not be used until standardized. Order of transmission shall be 
as specified in C.4.10 Order of transmission. For example, the LE Broadcast PDU shall begin 0, 


15.151, 0: 


Values 


caller 
responder 


ALE entity 


reason 


ALE entity 


none 


user process 


multicast 


group 
status 


user process 


Description 


11-bit 3G address of the calling station 


11-bit 3G address of the responding station 


LE_Link Fail Ind: issued by ALE process to indicate the failure 
of a link 


Reason for link failure; one of: NO.RESPONSE, REJECTED, 
NO_TRAF CHAN, LOW_QUALITY 


link has been requested or established 


LE_ReturnToScan: issued by user process to request termination 
of link and return to scanning operation; also used to reject an 
incoming link 


link has been requested or established 


LE_McastUpdate: issued by user process to add or delete a dwell] 
group from a multicast 


affected multicast address (same address used as member number 
in calls to all dwell groups) 


affected dwell group number 


one of: INCLUDED, EXCLUDED 


320 


MIL-STD-188-141B 
APPENDIX C 


6 3 6 5 


Called Member # 
(not 1111xx) 


LE Call PDU Call Tvpe Caller Member # Caller Group # 


6 3 7 


LE Handshake Link ID Command 
PDU 


Araument (e.a.. ch #) 


6 3 6 5 


LE Notification 
PDU 111111 Caller Status Caller Member # Caller Group # 


3 


LE Time Offset 


PDU Time Qualitv 


LE Group Time 
Broadcast PDU Server Group # 


3 3 


LE Broadcast 
PDU Countdown Call Tvpe Channel 


11 


LE Scannina Called Station Address 
Call PDU 


FIGURE C-17. 3G-ALE PDUs. 


C.5.2.2.1 LE Call PDU. 

The LE_Call PDU shall be formatted as shown in figure C-17. It conveys necessary information 
to the responder so that that station will know whether to respond, and what quality of traffic 
channel will be needed. 


The Call Type field in the LE Call PDU shall be encoded as specified in table C-X XII. 


e <Acall type of Packet Data shall be used only when the 3G data link protocol will be 
used to deliver a message after link establishment. 


e = The call type shall be Modem Circuit when an HF data modem using waveforms other 
than BW0-BWS will be used to convey traffic after link establishment. 


e The Voice Circuit call type requests a minimum link SNR suitable for orderwire voice 
operation (for example, 10 dB or better). 


e The High-Quality Circuit call type requests a substantially better SNR than an orderwire 
Voice Circuit (for example, 20 dB or better). 


e The unicast and multicast call types are used when the calling station will specify the 
traffic channel used for a link. 


e = The link release call type shall be used only when releasing, rather than establishing, a 
link. 
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TABLE C-XXII. Call type field encodings. 


Call Type Second PDU From 
3G ARQ Packet Data Responder 
HF Modem Circuit Responder 
Analog Voice Circuit Responder 


High-Quality Circuit | Responder 
Unicast ARQ Packet —_ Caller 


Unicast Circuit Caller 


Multicast Circuit Caller 


Control Caller 


C.5.2.2.2 LE Handshake PDU. 

The LE_Handshake PDU shall be formatted as shown in figure C-17. The link ID shall be 
computed as follows from the 11-bit addresses of the caller (node sending LE_Call PDU) and 
responder (node addressed in LE_Call PDU): 


1. temp = <caller address> * 0x13C6EF 
2. temp2 = <responder address> * 0x13C6EF 
3. LinkID =((templ >> 4) + (temp2>>15)) & Ox3f 


where ‘*’ indicates 32-bit unsigned multiplication, ‘>> n’ indicates right shift by n bits, and ‘&’ 
indicates bitwise AND. Example LinkID computations are shown below. 


Caller Responder temp! temp2 result result 
1 2 0013c6ef 00278dde 3D 61 
1 3 0013c6ef 003b54cd 24 36 
2 1 00278dde 0013c6ef 4 4 
3 1 003b54cd 0013c6ef 33 51 
1951 1 96b91771 0013c6ef 1E 30 
(decimal) (decimal) (hexadecimal) (hexadecimal) (hexadecimal) (decimal) 


The Command field shall be encoded as shown in table C-X XIII. Unused encodings are 
reserved, and shall not be used until standardized. 


322 


MIL-STD-188-141B 
APPENDIX C 


TABLE C-XXIII. Command field encodings. 


Command Description Argument 


Continue Handshake The handshake will continue for at least another two-way 
handshake (on the next assigned called station dwell 
frequency when operating in synchronous mode). 


Commence Traffic This is the final command sent on a calling channel. The Channel 
Setup argument is the channel number on which the responding 

station will (or should) listen for traffic setup. Following this 

command, all stations proceed to that traffic channel. 


Voice Traffic This command directs called station(s) to tune to a traffic Channel 
channel and commence voice traffic. The argument is the 
channel number. Following this command, the calling station 
will be first to speak. (Uni- and multicast only) 


Link Release This command informs all listening stations that the specified Channel 
traffic channel is no longer in use by the sending station. 


Sync Check This command directs the called station to measure and report Quality | Slot 
synchronization offset back to the calling station. Used in 
synchronization management protocol (C.5.2.7). 


Data This command is reserved for special-purpose protocols. The 
argument carries previously requested data. 


Abort Handshake This command immediately terminates the handshake and 
needs no response. It is analogous to the TWAS preamble in 
2G ALE. 


The Argument field shall contain a channel number, a reason code, or 7 bits of data, as indicated 
in table C-X XIII. Reasons shall be encoded as 7-bit integers with values selected from table 
C-XXIV. Unused encodings are reserved, and shall not be used until standardized. 


TABLE C-XXIV. Reason field encodings. 


NO_RESPONSE 


REJECTED 
NO_TRAF_CHAN 
LOW_QUALITY 


C.5.2.2.3 LE Notification PDU. 

The LE_Notification PDU shall be formatted as shown in figure C-17, and shall be used as 
specified in C.5.2.5 Notification Protocol Behavior. The Caller Member Number and Caller 
Group Number fields shall contain the address of the station sending the PDU. The Caller Status 
field shall be encoded as shown in table C-XXV. Unused encodings are reserved, and shall not 
be used until standardized. 
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TABLE C-XXV. Caller status field encodings. 


Code Station Status 


Nominal 
Time server 


Commencing EMCON 


Leaving network 


C.5.2.2.4 LE Broadcast PDU. 

The LE_Broadcast PDU shall be formatted as shown in figure C-17, and shall be used as 
specified in C.5.2.4.4.5 3G-ALE synchronous mode broadcast calling. 

The Call Type field shall describe the traffic to be sent: 


e Analog Voice Circuit if the receiving stations are to deliver the received audio directly. 
e HF Modem Circuit if an HF modem is to be engaged to process received traffic. 
e High-Quality Circuit if a non-HF modem is to be engaged to process received traffic. 


e 3G ARQ Packet Data if the link will be used in bidirectional mode using the CLC(see 
C.5.6) for channel access control. 


The Countdown field shall be used as specified in C.5.2.4.4.5 3G-ALE synchronous mode 
broadcast calling and in C.5.2.4.5.6 3G-ALE asynchronous mode broadcast call. 


C.5.2.2.5 Scanning call PDU. 
The LE Scanning Call PDU shall be formatted as shown in figure C-17, and shall be used as 
specified in C.5.2.4.5.2 3G-ALE asynchronous mode scanning call. 


C.5.2.2.6 CRC computation for 3G-ALE PDUs. 
Each LE_PDU contains either a 4-bit or an 8-bit CRC. The 4-bit CRC shall be computed in 
accordance with C.4.12 using the polynomial x* + x° +x + 1. The 8-bit CRC shall be computed 


in accordance with C.4.12 using the polynomial x° + x’+x*+x°+x41. 


C.5.2.3. Synchronous dwell structure. 

When scanning in synchronous mode, 3G systems shall dwell on each assigned channel for 4 
seconds. Each synchronous dwell time is divided into five slots of 800 ms each, which shall be 
used as follows (see figure C-18). 


Slot 0: Tune and Listen Time. During Slot 0, radio frequency (RF) components shall be retuned 
to the frequency on which the node may transmit during that dwell. 


e A scanning station shall tune to the assigned calling channel for that dwell, computed in 
accordance with C.4.4.1. Couplers are normally not retuned while scanning. 
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e A Station that will place a call during that dwell shall instead tune to the channel on 
which it will call during that dwell. The coupler may be retuned either in slot 0 or 
immediately before transmitting. 


Following tuning, every receiver shall sample a traffic frequency in the vicinity of the new 
calling channel, attempting to detect traffic. (This provides recent traffic channel status before 
stations get involved in a handshake.) 


Calling Slots. The remainder of the dwell time is divided into four 800 ms calling slots. These 
slots shall be used for the synchronous exchange of PDUs on calling channels. A two-way 
handshake shall not begin in the last slot of a dwell. The last slot of every dwell is reserved for 
LE_Handshake, LE Notification, and LE_Broadcast PDUs. 


eet Slot 1 Slat 2 Alot 3 Alot 4 


B00 rns B00 rns B00 ms B00 rns B00 rns Next clwvell 
(ew freq? 


FIGURE C-18. Synchronous dwell structure. 


C.5.2.4 3G-ALE protocol behavior. 
The behavior of the 3G-ALE protocol is specified in the following paragraphs in terms of data 


structures, states, events, actions, and state transitions. Note that these data structures, states, 
events, actions, and state transitions are not requirements of a compliant implementation, but 
only serve to illustrate the required over-the-air behavior of compliant systems. The data 
structures, events, and actions are listed in a single set of tables, which are used by both the 
synchronous-mode and asynchronous-mode protocol definitions. Separate behavior tables are 
specified for the two modes. 


C.5.2.4.1 3G-ALE protocol data. 
The internal variables used in the description of the 3G-ALE protocol are defined in table 


C-XXVI. These are for illustrative use only, and are not mandatory in implementations of 3G- 
ALE except as required elsewhere. 
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TABLE C-XXVI. 3G-ALE protocol data. 


callingChannel current dwell channel of destination station 


destStation ID of destination station (indiv, mcast, or beast) 


linkID Link ID value computed for current handshake 


linkQualityTable array of link quality records for all stations and channels 


prefTrafChan preferred traffic channel for current handshake partner 


myCallingSlot slot in which call will be sent 


bcastCount LE Broadcast PDU countdown (use varies between sync and async 
Imodes) 


numSeanChan 


trafWaitTimeMcast time called station will wait for traffic to start after link is established 
(longer time allowed for multicasts) 


C.5.2.4.2 3G-ALE protocol events. 

Table C-XXVII defines the events to which the 3G-ALE entity responds. The event names are 
used in the state transition tables in C.5.2.4.4.7 and C.5.2.4.5.9 which define the behavior of the 
3G-ALE protocol. 
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TABLE C-XXVII. 3G-ALE protocol events. 


D: LE_Link_ Req(destAddr, An LE Link Reg primitive was received from the user process (Connection 
callType, pri, [chan]) Manager); chan is optional 


D: LE_ReturnToScan An LE_ReturnToScan primitive was received from the user process 
(Connection Manager) 


R: LE_Call(destAddr, srcAddr, | received an LE_Call PDU 
callType) 


R: LE_ScanCall(destAddr) received an LE Scanning Call PDU for indicated destination address 
R: LE_Hshake(ID, CMD, ARG) | received an LE Handshake PDU 


R: LE_Bceast(countdown, received an LE_ Broadcast PDU 
callT ype, chan) 


FinishedSendingPDU occurs at end of slot (synchronous mode) or end of PDU (asynchronous mode) 


SlotAvailable Occupancy check of preceding slot(s) and analysis of any received PDUs 
indicates that no handshake in progress will extend into the slot now 


SlotOccupied Occupancy check of preceding slot(s) and analysis of any received PDUs 
indicates that a handshake in ae will extend into the slot now beginning 


liecsaceetnesiie | No response arrived within the timeout eee ee set 


ScanCallTimeout End of scanning call did not occur within allowed timeout 


ScanCallDropout Unable to identify BW0 preamble for three consecutive PDUs during scanning 
call timeout period 


Traffic did not begin within the timeout previously set 
TimeToSound(channel) Time to sound on indicated channel 


C.5.2.4.3 3G-ALE protocol actions. 
Table C-XXVIII defines the actions which the 3G-ALE entity can perform. The action name is 


used in the state transition tables used below to define the behavior of the 3G-ALE protocol. 
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TABLE C-XXVIII. 3G-ALE protocol actions. 


Action name Description 


ComputeDwellChannel(addr) Computes the current dwell channel for specified station at current 
networkTime 


Selects calling channel for best estimated connectivity to individual station 
using linkQualityTable (async mode only) 

Selects calling and traffic channels for best estimated connectivity to 
multicast subscribers using linkQualityTable 


Selects calling and traffic channels for best estimated connectivity to network 
members using linkQualityTable 


Initializes broadcastCount to number of times LE_ Broadcast PDU will be sent 
Sets broadcastCount to number 


Retune transceiver, PA, coupler, etc to specified channel; TuningComplete 
event when done 


SelectTrafficChannel(chan) Selects a traffic channel "near" specified channel, considering age of channel 
measurements 


ListenOnChannel(chan) Listen for occupancy on specified channel; FinishedListening event after 
preset interval 


RecordOccupancy(chan) store results of listening on chan in channelOccupancy array 


ListenForCalls(chan) Listen for 2G and 3G calls on specified channel; EndOfDwell event at end of 
current dwell 


SelectSlot(pri) Compute myCallingSlot using pri 


WaitForSlot(slot) Listens on myCurrentTrafficChannel until end of slot-1; SlotAvailable event i 
channel believed vacant, otherwise SlotOccupied (or R: xxx) event 


U: LE_Link_Ind(callerAddr, Inform user process (Connection Manager) that a link has been established 
allType) by a calling station 


-LE_Link_Confirm(destAdd) 
“LE Status Indstatus 
trafChan, caller, dest) been detected (link established or terminated) 
Inform user process (Connection Manager) that link has failed 


S: LE_Call(destAddr, srcAddr, Send an LE Call PDU 
trafType, pri) 


S: LE_Bcast(countdown, trafType,] Send an LE Broadcast PDU 
pri, chan) 


S: LE_Hshake(ID, CMD, ARG) Send an LE Handshake PDU 


InitResponseTimeout Set timeout for end of next slot 
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TABLE C-XXVIII. 3G-ALE protocol actions (continued). 


InitScanCallTimeout Set timeout for maximum allowed scanning call duration 
RestartSoundingTimer(chan, time)| Set timer to prompt next sound on channel 


InitAsyncCount Initialize asynchronous-mode broadcast countdown 


InitTrafWaitTimeout(time) Set timeout (trafWaitTime or trafWaitTimeMcast) to bound time waiting for 
traffic to start 


C.5.2.4.4 3G-ALE synchronous mode protocol. 
The synchronous-mode link establishment protocol shall comply with the following requirements 


as observed over the air. Precise definitions of the protocols are presented following overviews 
of the individual, multicast, and broadcast calling protocols. 


C.5.2.4.4.1 3G-ALE synchronous mode slot selection. 
The probability of selecting a slot for sending an LE_Call, LE_Broadcast, or LE_Notification 


PDU shall randomized over all usable slots, but the probabilities for higher-priority calls shall be 
skewed toward the early slots while lower-priority calls are skewed toward the later slots. (Such 
a scheme will operate reasonably well in all situations, while hard partitioning of early slots for 
high and late slots for low priorities would exhibit inordinate congestion in crisis and/or routine 
times.) Suggested sets of probabilities are shown in table C-XXIXa for LE_Call PDUs and table 
C-XXIXb for LE Broadcast and LE_Notification PDUs. 


TABLE C-XXIXa. Probability of slot selection for LE call PDUs. 


Call Priority Slot 1 


TABLE C-XXIXb. Probability of slot selection for LE broadcast and LE notification 
PDUs. 


Probability of Slot Selection for LE Broadcast and LE Notification PDUs. 


Call Priority Slot 1 Slot 2 Slot 3 Slot 4 
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A new random slot shall be selected for each dwell in which a call will be placed. Random 
number generation for slot selection shall be essentially independent from one dwell to the next, 
and among different stations, so that systems that select the same slot in one dwell will not have 
a higher than expected probability of continuing to select identical slots in subsequent dwells. 


C.5.2.4.4.2 3G-ALE synchronous mode individual calling overview. 

The one-to-one linking protocol identifies a frequency for traffic use relatively quickly (i.e., 
within a few seconds), and minimizes channel occupancy during this link establishment process. 
A station shall commence the link establishment protocol immediately upon receiving a request 
to establish a link with another station, unless it defers the start of calling until the called station 
will be listening on a channel believed to be propagating. The latter option serves to reduce 
channel occupancy, and does not preclude calling on the bypassed channels later if the link 
cannot be established on the favored channel. 


When a station needs to establish a link with another station, it shall send LE Call PDUs on the 
frequencies monitored by the called station until it receives a response, or until it has called on all 
calling channels at least once. The Call Type in the LE_Call PDU shall not be Unicast or 
Multicast in the individual calling protocol. In each dwell, the calling station shall do the 
following: 


e select a slot in accordance with C.5.2.4.4.1 3G-ALE synchronous mode slot selection; 
e listen on an associated traffic channel (if any) during Slot 0; 


e listen for occupancy on the calling slot channel during the slot immediately preceding its 
calling slot, if not calling in Slot 1; 


e defer its call as necessary until it believes the channel will not be occupied by a response 
PDU; 


e send its LE_Call PDU. 


A station that receives an LE_Call PDU addressed to its node address shall respond in the 
immediately following slot with an LE_ Handshake PDU that either aborts the call, names a 
traffic channel, or defers naming a channel but continues the handshake. When a suitable 
frequency for traffic to the responding station has been found, the stations shall enter the Traffic 
state. If additional negotiation is required (e.g., to set up a full duplex circuit using a second 
frequency), the ALM protocol shall be employed on the traffic channel. 


C.5.2.4.4.3 3G-ALE synchronous mode unicast calling. 
A unicast call is used to contact an individual station and direct it to a traffic channel selected by 
the calling station. 


1. An LE Call PDU shall be sent as usual, containing the individual responding-station 
address. The Call Type field shall be Unicast. No station shall respond to a Unicast-type 
LE_Call PDU. 
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2. The caller shall send an LE Handshake PDU in the immediately following response slot 
that directs the called station to a traffic channel. 


3. The called station shall tune to that channel and listen for modem traffic if the command 
in the LE Handshake PDU is Commence Traffic Setup. If the command is Voice 
Traffic, the called station shall tune to the channel and prepare for voice traffic (e.g., 
unmute the speaker). If the announced traffic does not begin to arrive within the traffic 
wait timeout, the called station shall return to scan. 


4. After sending the LE Handshake PDU, the caller shall tune to the specified channel and 
initiate the type of traffic indicated in the LE_Handshake PDU. 


Note that a unicast call may be used to set up a link for bidirectional traffic. 
C.5.2.4.4.4 3G-ALE synchronous mode multicast calling. 


A multicast call is used to contact selected stations concurrently and direct them to a traffic 
channel selected by the calling station. 


1. An LE Call PDU shall be sent as usual, but it shall contain a multicast responding- 
station address. The Call Type field shall be Multicast. No station shall respond to a 
Multicast-type LE_Call PDU. 


2. The caller shall send an LE Handshake PDU in the immediately following response slot 
that directs the called stations to a traffic channel. The link ID field shall be computed in 
accordance with C.4.5.3 Multicast addresses. 


3. The called stations shall tune to that channel and listen for modem traffic if the command 
in the LE Handshake PDU is Commence Traffic Setup. If the command is Voice 
Traffic, the called stations shall tune to the channel and prepare for voice traffic (e.g., 
unmute the speaker). If the announced traffic does not begin to arrive within the 
multicast traffic wait timeout, the called stations shall return to scan. (This timeout 
should be set to accommodate calls to the maximum number of dwell groups whose 
members may subscribe to the multicast.) 


4. When the stations subscribing to a multicast are assigned to more than one dwell group, 
the multicast call (both PDUs) shall be sent repeatedly by the caller. The caller should 
select the timing (and possible redundancy) of its transmissions to minimize calling 
channel occupancy while maximizing the probability of reaching called stations. 


5. After sending the (final) LE Handshake PDU, the caller shall tune to the specified 
channel and initiate the type of traffic indicated in the LE Handshake PDU. 


C.5.2.4.4.5 3G-ALE synchronous mode broadcast calling - not tested (NT) 


An LE Broadcast PDU directs every station that receives it to a particular traffic channel, where 
another protocol (possibly voice) will be used. A means shall be provided for operators to 
disable execution of the broadcast protocol. 
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e The Call Type field in the LE_Broadcast PDU shall be encoded as in the LE_Call PDU, 
except that only the circuit call types may be used. 


e The Countdown field shall indicate of the number of dwells that will occur between the 
end of the current dwell and the start of the broadcast. A Countdown value of 0 shall 
indicate that the broadcast will begin in Slot 1 of the following dwell. Other 
Countdown field values n _ 0 indicate that the broadcast will begin no later than 4n+3 
dwell times in the future. 


e The Channel field shall indicate the channel that will carry the broadcast. 


Slot selection for LE_Broadcast PDUs shall uses the same probabilistic approach as for LE_Call 
PDUs. However, a station may send an LE_Broadcast PDU in every slot in a dwell starting with 
the randomly selected slot. It may also change frequencies every slot to reach a new dwell group. 
The calling station shall check occupancy on the new calling channel before transmitting on that 
channel. A split-site station with a fast tuner may be able to send an LE_Broadcast PDU ona 
new channel in every slot by listening on the next channel each time and tuning at the start of the 
slot. A means shall be provided to override listen-before-transmit for highest-priority broadcasts 
that will permit transmission of an LE_Broadcast PDU on a new channel in every slot. 


Stations that receive an LE_Broadcast PDU and tune to the indicated traffic channel shall return 
to scan if the announced traffic does not begin within the traffic wait timeout period after the 
announced starting time of the broadcast. 


C.5.2.4.4.6 3G-ALE synchronous mode link release. 

At the conclusion of an individual or unicast link, the caller shall send a link release. The link 
release shall be an LE_Call PDU containing the original called station address, with a type of 
Control, followed by an LE_Handshake PDU that identifies the traffic channel and contains a 
link release command. 


The link release shall be sent on the calling channel on which the handshake that set up the link 
occurred. The calling station shall attempt to send the link release during the first dwell after the 
link is terminated during which the called dwell group is listening on that calling channel. The 
calling station need not attempt to send a link release later if calling channel occupancy during 
that dwell prevents transmission of the link release. 


C.5.2.4.4.7 3G-ALE synchronous mode protocol behavior. 
Implementations of 3G-ALE operating in synchronous mode shall exhibit the same over-the-air 
behavior as that described in table C-X XX. 
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TABLE C-XXX. 3G-ALE synchronous mode protocol behavior. 


End of dwell ComputeDwellChannel(mylIndivAddr) + S_Tune 
TuneToNewChannel(myCurrentDwellCha 
nnel) 


D: LE_Link_Req(dest, ComputeDwellChannel(dest) + C_Slot_Wait 
INDIV or UCAST, TuneToNewChannel(callingChannel) + 
trafType, pri) SelectSlot(pri) 


D: LE_Link_Req(dest, SelectMulticastChannel(dest) + C_Slot_Wait 
MCAST, trafType, pri) TuneToNewChannel(callingChannel) + 
SelectSlot(pri) 


D: LE_Link_Req(dest, SelectBroadcastChannel + C_Slot_Wait 
BCAST, trafType, pri) InitBroadcastCount + 
TuneToNewChannel(callingChannel) + 
SelectSlot(pri) 


R: LE_Call(mylndivAddr, |willing to link w/srcAddr & ComputeLinkID(srcAddr, mylndivAddr) + R_Commence 
isrcAddr, callType is good traffic channel S:LE_Hshake(linkID, COMMENCE, 
packet or circuit) known prefTrafChan) 


not willing to link with ComputeLinkID(srcAddr, mylndivAddr) + R_Abort 
srcAddr S:LE_Hshake(linkID, ABORT, 
UNAVAILABLE) 


illing to link w/srcAddr ComputeLinkID(srcAddr, mylndivAddr) + R_Continue 
but no traffic channel S:LE_Hshake(linkID, CONTINUE, 
known NO_CHANNEL) 


R: LE_Call(mylndivAddr, InitResponseTimeout R_Unicast 
srcAddr, UNICAST) 


R: LE_Call(dest, srcAddr, dest addr is in InitResponseTimeout R_Multicast 
MULTICAST) myMulticastAddresses 


R: LE_Call(dest, srcAddr, InitResponseTimeout R_Release 
LinkRelease) 


R: LE_Bcast(countdown, broadcasts accepted InitBcastCountdown(countdown) + R_Bcast 

trafType, pri, chan) broadcastPriority=pri + 
announcedBroadcastChannel = chan + 
ListenForCalls(myCurrentDwellChannel) 


others Scanning 


TTuningComplete SelectTrafficChannel(myCurrentDwellCh S_Listen 
annel) + 
ListenOnChannel(myCurrentTrafficChan 
nel) 


lothers queue or ignore 


FinishedListening RecordOccupancy(myCurrentTrafficCha Scanning 
nnel) + 
ListenForCalls(myCurrentDwellChannel) 


lothers queue or ignore S_Listen 
R_Release R: LE_Hshake(id, cmd, __ |id is correct, U: LE_Link_Det_Ind(Available, arg, Scanning 
larg) icmd=LinkRelease srcAddr, dest) + 
ListenForCalls(myCurrentDwellChannel) 
rong id or other ListenForCalls(myCurrentDwellChannel) Scanning 
command 


333 


MIL-STD-188-141B 
APPENDIX C 


TABLE C-XXX. 3G-ALE synchronous mode protocol behavior (continued). 


ResponseTimeout ListenForCalls(myCurrentDwellChannel) Scanning 
lothers none R_Release 


C_Slot_Wait [TuningComplete ListenOnChannel(myCurrentTrafficChann C_Slot_Wait 
el) 


FinishedListening WaitForSlot(myCallingSlot) C_Slot_Wait 


SlotAvailable individual call S: LE_Call(destAddr, mylndivAddr, SEND_CALL 
callType) 


unicast or multicast call S: LE Call(destAddr, mylndivAddr, SEND_CALL 
callType) 


broadcast call S: LE_Bcast(myCurrentTrafficChannel, SEND _BCAST 
callType) 


SlotOccupied myCallingSlot < 4 increment myCallingSlot + C_Slot_Wait 
WaitForSlot(myCallingSlot) 
myCallingSlot >= 4 compute/select next channel + C_Slot_Wait 
TuneToNewChannel(callingChannel) + 
SelectSlot(pri) 


R: 2G_Call 2G calls accepted U: 2G_Call_Ind Offline 


lothers queue or ignore S_Listen 


unicast or multicast call ComputeLinkID(mylIndivAddr, destAddr) + N_-Commence 
S:LE_Hshake(linkID, COMMENCE or 
VOICE, myCurrentTrafficChannel) 


SEND_CALL 


R: LE_Hshake(id, cmd, _ |id is correct, myCurrentTrafficChannel = arg + T_Tune 
larg) icmd=Commence TuneToNewChannel(myCurrentTrafficCh 
annel) 


id is correct, cmd = AbortU: LE_Link_Fail_Ind(reason = arg) Scanning 


ComputeNextDwellChannel(indivDest) + C_Slot_Wait 
TuneToNewChannel(callingChannel) + 
SelectSlot(pri) 


ResponseTimeout ComputeNextDwellChannel(indivDest) + C_Slot_Wait 
TuneToNewChannel(callingChannel) + 
SelectSlot(pri) 


ListenFor 
Response 


uningComplete U: LE_Link_Ind(CALLER, indivDest, LinkedAsCaller 
trafType, pri) 


IN_ Commence FinishedSendingPDU TuneToNewChannel(myCurrentTrafficCh N_Tune 
annel) 


lothers none N_Commence 
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TABLE C-XXX. 3G-ALE synchronous mode protocol behavior (continued). 


N_Tune TTuningComplete U: LE_Link_Ind(NCS, mcastDest, LinkedOneToMa 
trafType, pri) ny 


lothers none N_Tune 


ISEND_BCAS [FinishedSendingPDU lbroadcastCount = 1 TuneToNewChannel(myCurrentTrafficCh A_Tune 
annel) 


lbroadcastCount > 1, TuneToNewChannel(nextCallingChannel) B_Tune 
currentSlot<4 + decrementbroadcastCount 


lbroadcastCount > 1, TuneToNewChannel(nextCallingChannel) C_Slot_Wait 
currentSlot>=4 + SelectSlot(pri) + decrement 
broadcastCount 


lothers none SEND_BCAST 


uningComplete U: LE_Link_Ind(NCS, Broadcast, LinkedOneToMa 
callType) ny 


lothers none A_Tune 


B_ Tune uningComplete S: LE_Bcast(myCurrentTrafficChannel, SEND BCAST 
callType) 
lothers none B_Tune 


ee TuneToNewChannel(myCurrentTrafficch R_Tune 
annel) 


lothers none R_Commence 


FinishedSendingPDU Scanning 
lothers R_Abort 


IR_Continue =‘ |FinishedSendingPDU Scanning 
R_Continue 


IR: LE_Hshake(id, cmd, __|id is correct, cmd = myCurrentTrafficChannel = arg + R_Tune 
arg) Commence or Voice TuneToNewChannel(myCurrentTrafficCh 
annel) 


rong id or other ComputeDwellChannel(mylindivAddr) + Scanning 
command ListenForCalls(myCurrentDwellChannel) 


IRResponseTimeout ComputeDwellChannel(mylindivAddr) + = Scanning 
ListenForCalls(myCurrentDwellChannel) 


none R_Unicast 


IR: LE_Hshake(id, cmd, __ |id is correct, cmd = myCurrentTrafficChannel = arg + M_Tune 
arg) Commence or Voice TuneToNewChannel(myCurrentTrafficCh 
annel) 


rong id or other ComputeDwellChannel(mylndivAddr) + = Scanning 
command ListenForCalls(myCurrentDwellChannel) 


IResponseTimeout ComputeDwellChannel(mylindivAddr) + Scanning 
ListenForCalls(myCurrentDwellChannel) 
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TABLE C-XXX. 3G-ALE synchronous mode protocol behavior (continued). 


| others none R_Multicast 


EndOfDwell lbroadcastCount = 1 TuneToNewChannel( 
announcedBroadcastChannel) 


lbroadcastCount > 1 ComputeDwellChannel(mylindivAddr) + R_Bcast 
TuneToNewChannel(myCurrentDwellCha 
nnel) + decrementbroadcastCount 


uningComplete SelectTrafficChannel(myCurrentDwellCha R_Bcast 
nnel) + 
ListenOnChannel(myCurrentTrafficChann 
el) 


FinishedListening RecordOccupancy(myCurrentTrafficChan R_Bcast 


nel) 
R: 2G_Call 2G calls accepted U: 2G_Call_Ind Offline 


others none R_Bcast 


uningComplete U: LE_Link_Ind(RESPONDER, srcAddr, LinkedAsRespon 
callType) + der 
InitTrafWaitTimeout(trafWaitTime) 


uningComplete U: LE_Link_Ind(MEMBER, srcAddr, LinkedOneOfMa 
callType) + ny 
InitTrafWaitTimeout(trafWaitTimeMcast) 


LinkedAsCalle |D: LE_ReturnToScan TuneToNewChannel(callingChannel) + —LinkReleaseWait 
Ir SelectSlot(pri) 
lothers none LinkedAsCaller 


TuneToNewChannel(callingChannel) + LinkReleaseWait 
SelectSlot(pri) 


none LinkedOneTo 
Many 


dest group will dwell on WaitForSlot(myCallingSlot) LinkReleaseWait 
callingChannel 


dest group will dwellon none LinkReleaseWait 
another channel 


SlotAvailable S: LE_Call(destAddr, mylIndivAddr, LinkRelease1 
LinkRelease) 


SlotOccupied myCallingSlot < 4 increment myCallingSlot + LinkReleaseWait 
WaitForSlot(myCallingSlot) 


myCallingSlot >= 4 ComputeDwellChannel(mylindivAddr) + Scanning 
ListenForCalls(myCurrentDwellChannel) 


queue or ignore S_Listen 
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TABLE C-XXX. 3G-ALE synchronous mode protocol behavior (continued). 


LinkRelease1 |FinishedSendingPDU ComputeLinkID(mylIndivAddr, destAddr) LinkRelease2 
+ S:LE_Hshake(linkID, LinkRelease, 
myCurrentTrafficChannel) 


none LinkRelease1 


ComputeDwellChannel(mylindivAddr) + Scanning 
ListenForCalls(myCurrentDwellChannel) 


ComputeDwellChannel(mylIndivAddr) + Scanning 
ListenForCalls(myCurrentDwellChannel) 


ComputeDwellChannel(mylIndivAddr) + Scanning 
ListenForCalls(myCurrentDwellChannel) 
+ U:LE_Link_Fail_Ind(NORESPONSE)) 


none LinkedAsRespond 
er 


ComputeDwellChannel(mylIndivAddr) + Scanning 
ListenForCalls(myCurrentDwellChannel) 


ComputeDwellChannel(mylIndivAddr) + Scanning 
ListenForCalls(myCurrentDwellChannel) 
+ U:LE_Link_Fail_Ind(NORESPONSE)) 


none LinkedOneOf 
Many 


D: LE_ReturnToScan ComputeDwellChannel(mylndivAddr) + Scanning 
ListenForCalls(myCurrentDwellChannel) 


others none Offline 


C.5.2.4.4.8 3G-ALE synchronous mode protocol examples. 

An example of synchronous mode 3G-ALE protocol behavior is shown in figure C-19. The first 
call occurs in Slot 2. The responder receives the call, but has not identified a suitable traffic 
channel for the requested traffic, and therefore sends an LE_ Handshake PDU containing a 
Continue Handshake command. 


In the next dwell, both stations tune during Slot 0, then listen for occupancy on a nearby traffic 
frequency. The caller selects Slot 1 this time, and the responder has determined that the traffic 
channel was available. When the LE Call PDU is received by the responder, the measured 
channel quality is sufficient for the offered traffic, and the responder sends an LE_Handshake 
PDU containing a Commence Traffic Setup command that indicates the traffic channel to be 
used. Both stations tune to that channel in the following slot, and the caller initiates the traffic 
setup protocol. 


C.5.2.4.4.9 3G-ALE synchronous mode timing characteristics. 

Synchronous-mode 3G-ALE timing is specified in terms of Tsym, where 2400 Tsym = 1 s. The 
time at which each type of 3G-ALE PDU shall be sent is specified in the following paragraphs. 
In each case of sending a PDU, the transmitter shall have reached 90 percent of steady-state 
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power at the time that the PDU begins. Unless otherwise stated, deviation from specified timing 
shall not exceed +10 percent. 


Dwell Frame 
Caller 


ee 


Slot 3 


Caller 


Responder 


Commence 


Caller 


Responder ' Data Link Protocol startup 


(Listen) ! 
1 


FIGURE C-19. Example 3G-ALE synchronous link establishment. 


C.5.2.4.4.9.1 3G-ALE synchronous mode tuning time. 

All emanations for tuning the RF components in a synchronous-mode 3G-ALE system shall 
occur only during the first 256 T.ym (approximately 106.7 ms) of Slot 0, or between the start of a 
calling slot and the beginning of a PDU sent by that station in that slot. (Emanations required for 
the initial or learning tuning of a coupler with presets may occur at any time.) 


C.5.2.4.4.9.2 3G-ALE synchronous mode traffic channel evaluation timing. 

Synchronous-mode 3G-ALE systems shall listen for occupancy of a traffic channel during most 
of the remainder of Slot 0 during each scanning dwell , and shall meet the requirements of 
C.4.6.1.2 Occupancy detection. Normally, at least 640 ms should be available for this function, 
but no minimum time is required. The receiver shall be re-tuned to the calling channel in time to 
receive a PDU that begins coincident with the start of Slot 1. (NOTE: a PDU may arrive this 
early due to differences in local time bases.) 


C.5.2.4.4.9.3 3G-ALE synchronous mode call, broadcast, and notification timing. 

LE_ Call, LE Broadcast, and LE Notification PDUs shall be sent during slots selected in 
accordance with C.5.2.4.4.1 3G-ALE synchronous mode slot selection. The PDU shall begin at 
the later of the following two instants: 
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1. 128 Tyym (approximately 53.3 ms) has elapsed since the start of the selected slot. 


2. Ifand only if a PDU was received in the preceding slot, 256 Tsym (approximately 106.7 
ms) has elapsed since the end of that PDU. 


C.5.2.4.4.9.4 3G-ALE synchronous mode response timing 
A responding station shall commence transmission of an LE Handshake PDU at the later of the 
two following instants: 


1. 128 Tsym (approximately 53.3 ms) has elapsed since the start of the response slot at the 
responding station. 


2. 256 Tsym (approximately 106.7 ms) has elapsed since the end of the received LE_Call 
PDU. C.5.2.4.4.9.5 3G-ALE synchronous mode unicast, multicast, and link release 
command timing 


When a 3G-ALE system is sending a unicast or multicast call, or a link release, the 
LE_Handshake PDU that designates the traffic channel shall be sent in the slot that immediately 
follows the LE Call PDU. The transmitter shall be keyed when 128 Tyym (approximately 53.3 
ms) has elapsed since the start of that slot. 


C.5.2.4.5 3G-ALE asynchronous mode protocol. 

When a 3G-ALE network is operating in asynchronous mode, calls shall be extended to capture 
scanning receivers (similar to 2G-ALE) as described in C.5.2.4.5.2 3G-ALE asynchronous mode 
scanning call. The remainder of the handshake shall be self-timed as described in C.5.2.4.5.3 
3G-ALE asynchronous mode handshake. 


C.5.2.4.5.1 3G-ALE asynchronous mode listen before transmit. 

Systems operating in 3G-ALE asynchronous mode shall listen on the calling channel before 
sending a scanning call or a sound. The duration of this listen before transmit period shall be 
programmable, with a default value of 2 s. 


C.5.2.4.5.2 3G-ALE asynchronous mode scanning call. 

The LE Scanning Call PDU shall be sent repeatedly to capture scanning receivers, followed by 
an LE_Call PDU. The number of times the LE Scanning Call PDU is sent shall be a 
programmable multiple of the number of channels scanned (denoted C). By default, the 
multiplier M shall be 1.3. The number of LE Scanning Call PDUs sent shall be the smallest 
integer that is at least equal to the product of C and M. 


During a scanning call, only the first LE_Scanning Call PDU shall include Ty, (used for 
transmitter level control and receiver AGC settling). All succeeding LE Scanning Call PDUs 
and the LE Call PDU shall omit Ty, and include only the BWO preamble (Tpre) and data (Tata) 
portions. 
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C.5.2.4.5.3 3G-ALE asynchronous mode handshake. 
The asynchronous mode 3G-ALE handshake is self-timed. The responding station shall 


1. Decode an LE_Call PDU when it is received, 
2. Tune its RF components (if necessary), 
3. Listen on a traffic channel for approximately 640 ms to determine occupancy, and 


4. Key its transmitter for its response, in accordance with C.5.2.4.5.11.2 3G-ALE 
asynchronous mode handshake timing. 


The use of LE_Handshake PDU commands shall be the same as in the synchronous mode. 


If the calling station receives a Commence Traffic Setup command in the responding 
LE_ Handshake PDU, it shall commence the data link protocol (or ALM protocol, if required) 
starting 4 Tsiot = 3.2 s after the beginning of its LE_Call PDU. 


C.5.2.4.5.4 3G-ALE asynchronous mode unicast call. 

A unicast call is used to contact an individual station and direct it to a traffic channel selected by 
the calling station. An asynchronous-mode unicast call shall consist of a scanning call in 
accordance with C.5.2.4.5.2 3G-ALE asynchronous mode scanning call, with a Call Type of 
Unicast ARQ Packet, Unicast Circuit, or Control in the LE_Call PDU, followed immediately by 
an LE Handshake PDU that contains the following: 


e =A link ID (C.5.2.2) computed from the called station address and the calling station 
address. 


e A Voice Traffic command if requesting a link for analog voice traffic, or a Commence 
Traffic Setup command if requesting a link for other traffic types. 


e The channel number for the traffic channel that will be used for traffic. 


This LE_Handshake PDU shall not include Ty, but only the BWO preamble (Tyre) and data (Tdata) 
portions. 


C.5.2.4.5.5 3G-ALE asynchronous mode multicast call. 

A multicast call is used to contact selected stations concurrently and direct them to a traffic 
channel selected by the calling station. An asynchronous-mode multicast call shall consist of a 
scanning call in accordance with C.5.2.4.5.2 3G-ALE asynchronous mode scanning call, with a 
Call Type of Multicast in the LE_Call PDU, followed immediately by an LE_Handshake PDU 
that contains the following: 


e =A link ID (C.5.2.2) computed from the multicast address and the calling station address, 
in accordance with C.4.5.3 Multicast addresses. 
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e A Voice Traffic command if the link is for analog voice, otherwise a Commence Traffic 
Setup command. 


e The channel number for the traffic channel that will be used for the multicast. 


This LE_Handshake PDU shall not include Ty, but only the BWO preamble (Tyre) and data (Tata) 
portions. 


C.5.2.4.5.6 3G-ALE asynchronous mode broadcast call. 
The asynchronous-mode broadcast call shall consist of at least M C + 1 repetitions of an 


LE_Broadcast PDU, where C is the number of calling channels scanned by the stations being 
called, and M is the multiplier defined in C.5.2.4.5.2 3G-ALE asynchronous mode scanning call. 
The Call Type and Channel fields shall be used as specified in C.5.2.4.4.5 3G-ALE synchronous 
mode broadcast calling. The Countdown field shall be used as follows: 


1. A repetition factor R shall be computed as the smallest integer that is greater than or 
equal to M C/ 7. For example, if M = 1.2 and C = 10, R shall be 2. 


2. The initial value of the Countdown field shall be the smallest integer that is greater than 
or equal to M C/R. For example if M = 1.2 and C = 10, the initial Countdown value 
shall be 6. 


3. R identical repetitions of the LE Broadcast PDU shall be sent, after which the 
Countdown field shall be decremented. 


4. Step 3 shall be repeated until the decremented value of the Countdown field is 0. A 
single instance of the LE_Broadcast PDU with Countdown = 0 shall be sent. 


5. The broadcast shall commence on the indicated channel 2 T,).; after the end of the final 
LE_ Broadcast PDU. 


During an asynchronous-mode broadcast call, only the first LE_Broadcast PDU shall include Tic 
(used for transmitter level control settling). All succeeding LE Broadcast PDUs shall omit Ty, 
and include only the BWO preamble (Tpre) and data (Tdata) portions. 

A means shall be provided for operators to disable execution of the asynchronous-mode 
broadcast protocol. 


C.5.2.4.5.7 3G-ALE asynchronous mode link release. 

Transmission of link releases is optional when operating in asynchronous mode. When used, an 
asynchronous-mode link release shall be sent after termination of a link on the calling channel 
that was used in establishing the link. Asynchronous-mode link releases shall begin with a 
scanning call addressed to the called station in accordance with C.5.2.4.5.2 3G-ALE 
asynchronous mode scanning call, with a Call Type of Link Release in the LE_Call PDU, 
followed immediately by an LE_Handshake PDU that contains the following: 


e A link ID computed from the called address and the calling station address. 
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e A Link Release command. 


e The channel number for the traffic channel that is being released. 


This LE_Handshake PDU shall not include Ty, but only the BWO preamble (Tyre) and data (Tata) 
portions. 


C.5.2.4.5.8 3G-ALE asynchronous mode entry to synchronous networks. 
Stations not synchronized to network time may link with synchronous mode stations by sending 


either normal (C.5.2.4.5.2) or extended scanning calls addressed to those stations. The duration 
of an extended scanning call is 4 C seconds, which ensures that the destination station will dwell 
on the calling channel during the call. 


C.5.2.4.5.9 3G-ALE asynchronous mode protocol behavior. 
Implementations of 3G-ALE operating in asynchronous mode shall exhibit the same over-the-air 


behavior as that described in table C-X XXI. 
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TABLE C-XXXI. 3G-ALE asynchronous mode protocol behavior. 


Event 
End of dwell 


D: LE_Link_Req( indivDest, 


rafType, pri) 


D: LE_Link_Req( mcastDest, 
rafType, pri) 


D: LE_Link_Req( Broadcast, 
rafType, pri) 


R: LE_Scan_Call(addr) 


R: LE_Bcast(countdown, 
rafType, pri, chan) 


imeToSound(channel) 


others 


FinishedListening 


uningComplete 


others 


FinishedSendingPDU 


others 


IR: LE_Call(mylndivAddr, 
rcAddr, pkt or ckt call) 


R: LE_Call(mylndivAddr, 
rcAddr, UNICAST) 


Condition 


addr is mylndivAddr or is 
subscribed multicast or 
listening for LinkReleases 


broadcasts accepted 


sounding enabled 


channel occupied 


channel vacant 


iscanSoundCountdown > 1 


iscanSoundCountdown <= 


R: LE_Call(destAddr, srcAddr, destAddr is in 


MULTICAST) 
R: LE_Call(dest, srcAddr, 


LinkRelease) 
ScanCallTimeout 


ScanCallDropout 


others 


myMulticastAddresses 


Action 


ComputeDwellChannel(mylndivAddr) + 
ListenForCalls(myCurrentDwellChannel) 


SelectCallingChannel(indivDest) + 
ListenOnChannel(callingChannel) 


SelectMulticastChannels(mcastDest) + 
ListenOnChannel(callingChannel) 


SelectBroadcastChannels + InitBroadcastCount + 
ListenOnChannel(callingChannel) 


InitScanCallTimeout 


InitBcastCountdown(countdown) + 
broadcastPriority=pri + announcedBroadcastChannel 
= chan 


callingChannel = channel + 
ListenOnChannel(myCurrentTrafficChannel) 


none 


RecordOccupancy(callingChannel) + 
RestartSoundingTimer(callingChannel, 
soundRetryDelay) + 
ListenForCalls(myCurrentDwellChannel) 


TuneToNewChannel(callingChannel) + 
RestartSoundingTimer(callingChannel, 
soundingInterval) 


queue or ignore 
S: LE_Notification(mylndivAddr, NOMINAL) + 
scanSoundCountdown = 1.2 * numScanChan 
queue or ignore 
S: LE_Notification(mylndivAddr, NOMINAL) + 


scanSoundCountdown = scanSoundCountdown - 1 


1 ComputeDwellChannel(mylndivAddr) + 
ListenForCalls(myCurrentDwellChannel) 
queue or ignore 
TuneToNewChannel(myCurrentDwellChannel) 
InitResponseTimeout 
InitResponseTimeout 


InitResponseTimeout 


ComputeDwellChannel(mylndivAddr) + 
ListenForCalls(myCurrentDwellChannel) 


ComputeDwellChannel(mylndivAddr) + 
ListenForCalls(myCurrentDwellChannel) 


queue or ignore 
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Next State 


Scanning 


C_Listen 


C_Listen 


C_Listen 


ListenToCall 


R_Bcast 


S_Listen 


Scanning 


Scanning 


S_Listen 


SendSound 


S_Tune 


SendSound 


Scanning 


SendSound 


L_Tune 


R_Unicast 


R_Multicast 


R_Release 


Scanning 


Scanning 


ListenToCall 
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TABLE C-XXXI. 3G-ALE asynchronous mode protocol behavior (continued). 


Condition Action Next State 


illing to link w/srcAddr SelectTrafficChannel(myCurrentDwellChannel) + R_Listen 
ListenOnChannel(myCurrentTrafficChannel) 


not willing to link with ComputeLinkID(srcAddr, mylndivAddr) + 
srcAddr $:LE_Hshake(linkID, ABORT, REJECTED) 


queue or ignore 


id is correct, U: LE_Link_Det_Ind(Available, arg, srcAddr, dest) + | Scanning 
icmd=LinkRelease ListenForCalls(myCurrentDwellChannel) 
rong id or other command _ListenForCalls(myCurrentDwellChannel) Scanning 
ResponseTimeout ListenForCalls(myCurrentDwellChannel) Scanning 
others none R_Release 
tafic channel occupied ComputeLinkID(srcAddr, mylndivAddr) + R_Continue 
S:LE_Hshake(linkID, CONTINUE, NO_CHANNEL) 
raffic channel vacant ComputeLinkID(srcAddr, mylndivAddr) + R_Commence 
S:LE_Hshake(linkID, COMMENCE, prefTrafChan) 
queue or ignore R_Listen 
R_Commence |FinishedSendingPDU Tune ToNewChannel(myCurrentTrafficChannel) R_Tune 
ae none R_Commence 
R_Abort FinishedSendingPDU none Scanning 
lothers none R_Abort 


R_Continue —|FinishedSendingPDU Scanning 
lothers R_Continue 


IR_Unicast IR: LE_Hshake(id, cmd, arg) __|id is correct, cmd = myCurrentTrafficChannel = arg + R_Tune 
Commence or Voice Tune ToNewChannel(myCurrentTrafficChannel) 
rong id or other command ComputeDwellChannel(mylndivAddr) + Scanning 
ListenForCalls(myCurrentDwellChannel) 
ResponseTimeout ComputeDwellChannel(mylndivAddr) + Scanning 
ListenForCalls(myCurrentDwellChannel) 
lothers none R_Multicast 


R_Multicast R: LE_Hshake(id, cmd, arg) _|id is correct, cmd = myCurrentTrafficChannel = arg + M_Tune 
Commence or Voice TuneToNewChannel(myCurrentTrafficChannel) 


rong id or other command ComputeDwellChannel(mylndivAddr) + Scanning 
ListenForCalls(myCurrentDwellChannel) 


ResponseTimeout ComputeDwellChannel(mylndivAddr) + Scanning 
ListenForCalls(myCurrentDwellChannel) 


lothers none R_Multicast 


IR: LE_Bcast(countdown, ountdown = 0 TuneToNewChannel(chan) M_Tune 
rafType, pri, chan) 


countdown > 0 none R_Bcast 
lothers none R_Bcast 
uningComplete U: LE_Link_Ind(RESPONDER, srcAddr, trafType, pri) LinkedAsResponder 
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TABLE C-XXXI. 


Condition 


uningComplete 


others 


channel occupied 


others 


IR: LE_Hshake(id, cmd, arg) 


id is correct, 
md=Commence 


id is correct, cmd=Abort 


rong id or other command 


Response Timeout 


U: LE_Link_Ind(MEMBER, srcAddr, trafType, pri) 


none 


ComputeDwellChannel(mylndivAddr) + 
ListenForCalls(myCurrentDwellChannel) 


none 


ComputeDwellChannel(mylndivAddr) + 
ListenForCalls(myCurrentDwellChannel) 


none 


ComputeDwellChannel(mylndivAddr) + 
ListenForCalls(myCurrentDwellChannel) 


none 


Tune ToNewChannel(callingChannel) 


RecordOccupancy(callingChannel) + 
SelectCallingChannel(indivDest) + 
ListenOnChannel(callingChannel) 


queue or ignore 


S$: LE_Scan_Call(destAddr) 
S$: LE_Scan_Call(mcastAddr) 


InitAsyncCount + S: LE_Bcast(bcastCount, trafType, 
pri, myCurrentTrafficChannel) 


queue or ignore 


ComputeLinkID(mylndivAddr, indivDest) + 
InitResponseTimeout 


ComputeLinkID(mylndivAddr, mcastDest) + 
S:LE_Hshake(linkID, COMMENCE or VOICE, 
myCurrentTrafficChannel) 


myCurrentTrafficChannel = arg + 


TuneToNewChannel(myCurrentTrafficChannel) 


U: LE_Link_Rejected(reason = a 


RecordCallFailure(indivDest, callingChannel) + 
SelectCallingChannel(indivDest) 
ListenOnChannel(callingChannel 


RecordCallFailure(indivDest, callingChannel) + 
SelectCallingChannel(indivDest) + 
ListenOnChannel(callingChannel 


U: LE_Link_Ind(Caller, indivDest, trafType, pri) 


3G-ALE asynchronous mode protocol behavior (continued). 


Next State 
R_Tune 


LinkedOneOfMany 
M_Tune 


Scanning 


LinkedAs Caller 


Scanning 


LinkedOneTo Many 


Scanning 


LinkedAs Responder 


C_Tune 
C_Listen 


C_Listen 


SendScanCall 
SendScanCall 


BroadcastCall 


S_Listen 


ListenForResponse 


N_Commence 


SendScanCall 


T_Tune 


Scanning 
C_Listen 


C_Listen 


ListenFor Response 


LinkedAsCaller 
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TABLE C-XXXI. 3G-ALE asynchronous mode protocol behavior (continued). 


State Event Condition Action Next State 


IN Commence |FinishedSendingPDU TuneToNewChannel(myCurrentTrafficChannel) N_Tune 
others none N_Commence 


N_Tune uningComplete U: LE_Link_Ind(NCS, mcastDest, trafType, pri) LinkedOneToMany 
others none N_Tune 


BroadcastCall |FinishedSendingPDU uneToNewChannel(myCurrentT rafficChannel) 


countdown > 0 update bcastCount + S: LE_Bcast(bcastCount, BroadcastCall 
trafType, pri, myCurrentTrafficChannel) 


none BroadcastCall 


uningComplete U: LE_Link_Ind(NCS, Broadcast, trafType, pri) LinkedOneToMany 


others none A_Tune 


C.5.2.4.5.10 3G-ALE asynchronous mode protocol example. 

The asynchronous mode 3G-ALE protocol is illustrated in figure C-20. The called station 
(“Responder’’) receives a scanning call and evaluates the channel quality of the calling channel 
using the received LE Scanning Call and LE Call PDUs. Having determined that the channel 
quality is sufficient for the type of traffic announced in the LE_Call PDU, the Responder tunes 
on the calling channel for sending a response, listens on a nearby traffic channel, finds the traffic 
channel unoccupied, and therefore sends a Commence Traffic Setup command in an 
LE_Handshake PDU. 


Caller 


Responder Scan Call Scan Call Scan Call 
(Tune) 
Commence 
920 ms 


Traffic Freq 


Data Link Protocol startup 
(Tune) 


Responder 


FIGURE C-20. 3G-ALE asynchronous mode link establishment. 


C.5.2.4.5.11 3G-ALE asynchronous mode timing characteristics. 
Asynchronous mode timings are referenced only to the start of the scanning call, not to any 


global timing system. Unless otherwise stated, deviation from specified timing shall not exceed 
+10 percent. 
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C.5.2.4.5.11.1 3G-ALE asynchronous mode scanning call timing. 

The duration of a 3G-ALE asynchronous-mode scanning call (including LE Scanning Call 
PDUs and the LE_Call PDU) shall be as follows, where C is the number of scanned channels, 
and M is the multiplier of C.5.2.4.5.2 3G-ALE asynchronous mode scanning call. 


Tse = Tule + (M C + 1) (Tsawo pre + Tpwo data) 
= 2.640s when C = 3 calling channels, and M = 1.3 


When an LE Handshake PDU is appended to the LE_Call PDU, Ts is increased by Tpwo pre + 
Tpwo data OF approximately 506.7 ms. 


C.5.2.4.5.11.2 3G-ALE asynchronous mode handshake timing. 
When an LE_ Handshake PDU is sent by a responding station, it shall begin 32 Tsym 


(approximately 13.3 ms) after the transmitter is keyed. Total elapsed time from end of LE_Call 
PDU until start of LE_Handshake PDU shall be 2208 Tsym (920 ms), measured at the responding 
station. 


The duration of a 3G-ALE asynchronous-mode handshake, from the start of the scanning call 
through the start of traffic setup on the traffic channel is as follows: 


Thandshake = Tue +MC (Tpwo pre or Tpwo data) + 4 T slot 
= 5.333 s when C = 3 calling channels, and M = 1.3 


C.5.2.5 Notification protocol behavior. 
Sending LE Notification PDUs is optional. Network managers may wish to enable the 


notification protocol when the use of channel time for this overhead function provides a 
worthwhile return in tracking station and channel status. 


C.5.2.5.1 Station status notification. 
When station status notification is enabled, stations shall broadcast an LE_Notification PDU 
when one of the following occurs: 


e Station status changes (or is about to change to a non-communicative state). 


e A periodic timer prompts a notification. 


A notification shall be sent on one or more channels selected to efficiently inform other network 
members of station status. 


C.5.2.5.2 Sounding. 

Sounding will normally be unnecessary in 3G-ALE systems. Knowledge of propagating 
channels can be used in synchronous networks to delay the start of calling and thereby reduce 
calling channel occupancy. However, with synchronous scanning, knowledge of propagating 
channels will have only slight effect on linking latency unless non-propagating channels are 
removed from the scan list (see Calling Channel Management, above). 


347 


MIL-STD-188-141B 
APPENDIX C 


In asynchronous 3G-ALE networks, sounding may be desired if propagation data is unobtainable 
by other means. In this case, periodic transmissions of a repeated LE_Notification PDU 
indicating Nominal station status may be employed. 


C.5.2.5.3 Synchronous mode notifications. 

In networks operating in synchronous mode, LE_Notification PDUs shall be sent singly in 
randomly selected slots using the same procedure as for LE_Call PDUs, including slot selection 
and listening before transmitting. 


C.5.2.5.4 Asynchronous mode notifications. 

In networks operating in asynchronous mode, LE_ Notification PDUs shall be sent MC + 1 
times, after listening before transmitting, where C is the number of scanned channels, and M is 
the multiplier of C.5.2.4.5.2 3G-ALE asynchronous mode scanning call. 


C.5.2.6 Calling into a 3G network. 

Stations that have not been assigned an address in a network may call into that network by 
randomly selecting a Net Entry address (C.5.2.6.1) and placing a call using that address in 
accordance with an appropriate calling protocol. The call may be placed on any frequency 
known to be monitored by the network to be entered. Networks that support net entry by non- 
member stations should assign a well-known address (e.g., all 0’s) to field such calls. Linking 
protection should be employed when spoofing is a concern. 


Net entry calling and acceptance of net entry calls shall be supported by all 3G systems. A means 
shall be provided for operators to disable acceptance of net entry calls. 


C.5.2.6.1 Net entry addresses. 

Net Entry addresses are of the form 1111xxxxxxx. A station placing a net entry call shall 
randomly select one of these 128 addresses for use in a 3G-ALE calling protocol and subsequent 
protocols until it is assigned a member address. 


C.5.2.6.2 Link establishment for net entry. 

A station calling into a network operating in synchronous or asynchronous mode shall place an 
asynchronous-mode unicast call to a well-known address in accordance with C.5.2.4.5.4 3G-ALE 
asynchronous mode unicast call. When the calling station does not know the channel 
assignments in the foreign network, it should specify channel 127 which results in linking for 
traffic on the calling channel. When more than one of the frequencies scanned by the destination 
network are known, calling attempts should be placed on each channel in rotation until a link is 
established. 


If the calling station seeks only a one-time analog voice link, the Call Type should be “Unicast 
Circuit” and the LE Handshake PDU should carry a Commence Voice command. Otherwise, 
the TM protocol will normally be engaged after linking, so the Call Type should be “Unicast 

ARQ Packet” and the LE_Handshake PDU should carry a Commence Traffic Setup command. 
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C.5.2.6.3 Acquisition of operating data. 

When a station calling into a network is to begin regular operation as a network member, the 3G 
packet protocol and the network management protocol of Appendix D should be used to transfer 
the following network operating data to the entering station: 


e A station self address for use in the newly entered network (not a net entry address). 
Normally the calling station will provide its call sign and receive a 3G ALE (11 bit ) 
address in return. 


e Channel table (frequencies, usage flags, and power limits); see C.4.11.3. 


This transfer may be accomplished during the traffic phase of the initial net entry call, using the 
net entry address. 


Synchronization of the entering station with network time shall comply with C.4.3 Network 
synchronization. If over-the-air synchronization will be required, it is recommended that 
operating data be set up in the new network member before the net entry synchronization 
protocol of C.5.2.7.6 is executed. 


C.5.2.7 Synchronization management protocol (not tested). 

3G networks operating in synchronous mode are intended to maintain synchronization using 
external means such as GPS receivers. This section describes a synchronization management 
protocol that is intended to serve as a fallback mechanism for use when external time references 
are unavailable or their use is otherwise impractical. Network managers should avoid use of this 
protocol when other alternatives are available because it requires use of the HF channels for this 
overhead function. 


The synchronization management protocol supports the following tasks: 


e Synchronization maintenance to compensate for time base drift 
e Time service for late net entry 


e Initial distribution of time to network member stations 


This is an optional protocol. However, all 3G networks that must operate without external 
synchronization available to every station should implement these functions. 


C.5.2.7.1 Synchronization data. 

For successful operation in synchronous mode, third generation systems must maintain time base 
accuracy in accordance with C.4.3. The formula used by synchronous-mode stations to compute 
their current dwell channels in C.4.4.1 includes the time since midnight (network time). Network 
time is conceptually stored as a GPS week counter (week 0 was the week beginning 00:00 6 
January 1980), a day of the week, elapsed seconds in the current day, and elapsed Tsym within 
the current second. A dwell counter is extracted from the seconds counter by dropping the two 
least-significant bits. Note that GPS time runs at the same rate as coordinated universal time 
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(UTC), but GPS time does not add leap seconds and therefore differs by a small number of 
seconds from UTC. 


In addition to a local estimate of network time, each station shall maintain a bound on the 
uncertainty (loss of accuracy) of this time base. This uncertainty value shall be set when the time 
base is adjusted, as described later, and shall increase steadily until the next time base update at a 
rate determined by the accuracy of the time base oscillator. When the oscillator has an accuracy 
of 1 part per million, the time base may drift by +/— 3.6 ms per hour, so the total width of time 
base uncertainty shall be increased by 7.2 ms per hour. 


C.5.2.7.2 Time quality. 
When one station sends a time update to another station, the uncertainty at the sending station 


shall be encoded as a Time Quality code in accordance with table C-X XXII. Note that only UTC 
sites may claim Time Quality 0. Stations that receive regular updates from a local GPS receiver 
or other stable time base that maintains their uncertainty below | ms shall report Time Quality 1. 
Other stations shall use the smallest code whose corresponding uncertainty value is greater than 
or equal to the local total uncertainty width. 


TABLE C-XXXII. 3G-ALE synchronization management time quality codes. 
SM Time Quality Code Total Time Uncertainty 
0 (000) none: UTC station 
1 (001) 1 ms: local GPS receiver or equiv. 


2 (010) 2 ms or stand-alone master station 


3 (011) 5 ms 

4 (100) 10 ms 

5 (101) 20 ms 

6 (110) 50 ms 

7(11) unbounded or unknown 


NOTE: When a network is operating in stand-alone mode (i.e., no network member has 
access to UTC, GPS, or equivalent time), one network member station should be designated 
as the master time reference, and that station should always use Time Quality 2. Of all 
station that have suitably stable oscillators, the designated station may be selected as the one 
with the lowest 3G-ALE address (e.g., a designated net entry server, with address zero). 


C.5.2.7.3 Synchronization management PDUs. 
The LE_PDUs (see figure C-17) used in synchronization management are described in the 
following paragraphs. 


C.5.2.7.3.1 Group time broadcast PDU. 

The group time broadcast PDU (LE_GTB PDU) conveys limited-precision time to any station 
that receives it. It is sent singly as described later in this section. The Server Group Number 
shall contain the dwell group number portion of the sending station address. The Dwell Number 
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field shall contain the four least-significant bits of the counter of dwell periods since midnight 
network time. The Slot Number field shall indicate the slot in which the PDU is sent. (The Slot 
Number field is set to 7 during initial time distribution, as described in C.5.2.7.5.) 


An LE_GTB PDU shall always be sent starting 128 Tsym after the beginning of the indicated 
slot at the sender. However, receiving stations may not know the propagation delay from sender 


to receiver, so this PDU by itself is insufficient to synchronize stations to meet the requirements 
of C.4.3. 


NOTE: each day contains an even multiple of 16 dwells so the four Dwell Number bits sent 
in this PDU increment naturally from 1111 to 0000 at midnight. The time indicated by this 
PDU should never be ambiguous unless (and only when) network time adds a leap second. 
For this reason, GPS time may be preferred over UTC. 


C.5.2.7.3.2 Syne check PDU. 

The Sync Check PDU is an LE_Handshake PDU containing a Sync Check command. It is sent 
following a Control-type LE_Call PDU during a sync check handshake, and shall always be sent 
128 Tsym after the beginning of its slot at the sending station. 


The most-significant bit of the Argument field shall be 0. The next three bits shall contain the 

time quality code from table C-X XXII corresponding to the total time uncertainty at the station 
sending the PDU. The three least-significant bits shall contain the number of the slot in which 
the PDU is sent: 001, 010, 011, or 100. 


The Argument field may be set to all 1’s when used in Late Net Entry Sync Acquisition (see 
C.5.2.7.6). 


C.5.2.7.3.3 Sync offset PDU. 

The LE_Sync Offset PDU is used to compensate for time base drift and propagation delay among 
stations during a Sync Check Handshake. It shall be sent by the responding station 256 Tsym 
(+/- 1 ms) after the end of a Sync Check PDU. The Quality field shall contain the time quality of 
the responding station in accordance with C.5.2.7.2. The Offset field shall indicate the 
magnitude of the difference between the time when the end of the Sync Check PDU arrives at the 
responding station and the “ideal time” when a PDU sent by the responding station in that same 
slot would have ended (i.e., beginning of the slot plus 128 Tsym plus 613 ms, which is 1600 
Tsym or 666.7 ms into the slot). The Offset field shall be encoded in accordance with table 
C-XXXIII. The Sign bit shall be 1 if the PDU arrived early (before the ideal time), 0 if it arrived 
after the ideal time. 
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TABLE C-XXXIII. 3G-ALE synchronization management sync offset codes. 
Sync Offset Code Magnitude of Offset (ms) 
0 - 400 2 x Code 


401 - 420 (reserved; do not use) 


421-511 40 x (Code - 400) 


C.5.2.7.4 Syne check handshake. 

The sync check handshake is used to update the time base at the station that initiates the 
handshake. It consists of a Control-type LE_Call PDU, followed by an LE_ Sync Check PDU 
from the initiator. The called station then responds with an LE_Sync Offset PDU. The initiating 
station shall compute its new local time and total time uncertainty as follows after receiving the 
LE_ Sync Offset PDU: 


1. The initiator shall measure the elapsed time between the end of its Sync Check PDU and 
the time of arrival of the end of the LE_Syne Offset PDU. The propagation delay Tpa 
shall be computed as Tpa = (Elapsed time - 720 ms) / 2. 


2. Ifthe LE Sync Offset PDU Sign field is 0 (initiator is behind), the initiator shall subtract 
Tpd from the Offset field and add the result to its local time. Otherwise (Sign field = 1), 
the initiator shall add Tyq to the Offset field and subtract the result from its local time. 


3. The initiator shall set its time base uncertainty to the value corresponding to the Quality 
code in the LE_ Sync Offset PDU plus 5 ms to allow for unmeasured fluctuations in time 
of PDU release and in propagation delay. 


A syne check handshake shall begin with equal probability in slot 1 or slot 2, and shall not begin 
in later slots. 


C.5.2.7.5 Synchronization maintenance. 
Stations operating in synchronous mode should request a time base update whenever their total 


time uncertainty will increase past the maximum allowed tolerance (C.4.3) within 60 minutes. A 
sync check handshake should then be initiated with the time server in its group. If no response 
(or a garbled response) is received, the initiating station should try again C + 1 dwells later on the 
next channel, and so on. 


If a station’s time uncertainty grows past the limit of C.4.3, it must cease synchronous operation 
and attempt to reacquire network synchronization using the Late Net Entry procedure specified in 
C.5.2.7.6. 


C.5.2.7.6 Synchronization for late net entry. 
A station that is not synchronized to a network but whose time base is within +/- 30 s of network 


time may request and synchronize to network time using the following protocol. The protocol is 
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more robust if the unsynchronized station knows the channel assignments of the network (see 
step 3), but may be used by a station that knows only one frequency that is monitored by the 
network stations. 


1. 


The unsynchronized station (caller) initiates the protocol by sending an asynchronous 
Control call to a time server or other known address. The caller may use either a Net 
Entry address (C.5.2.6.1) or a network member address assigned as described in 
C.5.2.6.3. The call shall consist of LE Scanning Call PDUs addressed to the called 
station (responder), a Control type LE_Call PDU addressed to the responder, and an 
LE_Syne Check PDU with the Argument field set to all 1s. This special value in the 
Argument field indicates that the call is a time request rather than a sync maintenance 
request. 


In response to an LE_Sync Check PDU with the Argument field set to all 1s, the 
responder will return an LE_GTB PDU rather than a Sync Offset PDU. The LE_GTB 
PDU shall be sent 128 Tsym after the slot boundary the follows the end of the received 
LE_ Sync Check PDU, and shall report the slot number of the slot it occupies (which may 
be slot 0). The LE_GTB PDU shall be sent on the frequency that carried the call. After 
sending the LE_ GTB PDU, the responder shall remain on the same frequency, ignore the 
next slot and check the slot after that for an LE Call PDU. 


The caller should correct its local time using the time contained in the LE_GTB PDU, 
with the assumption that propagation time from the responder was zero, and set its time 
uncertainty to 70 ms. It should then initiate the synchronization maintenance protocol 
described above (C.5.2.7.4) in the second slot after the LE_GTB PDU. If no response (or 
a garbled response) is received, the station may continue to attempt Sync Check 
handshakes with the responder on the responder’s assigned dwell channels using the 
formula in C.4.4.1 if it knows the calling channels in use in the network. Otherwise it 
must restart this protocol at step 1. 


If the responder receives error-free LE_Call and LE Handshake PDUs containing the 
expected fields for a Sync Check handshake from the entering station, it shall complete 
the handshake by sending an LE_Sync Offset PDU as described in C.5.2.7.3.3. After 
sending this PDU, or after failing to receive the appropriate PDUs, the responder shall 
return to the Scanning state on its then-current assigned dwell channel. 


An entering station shall not place any other synchronous call to the network until this 
synchronization is completed. 


C.5.2.7.7 Initial time distribution. 

Before a network is synchronized, stations should be scanning in asynchronous mode. Initial 
time distribution to a network begins with an asynchronous mode notification sequence, followed 
by an LE _ GTB PDU from the master time station for the network (e.g., station 0). The repeated 
LE_Notification PDU shall contain the master time station address and a status of Time Server. 
The LE_GTB PDU shall contain a Slot Number value of seven, which indicates that the initial 
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time distribution protocol is commencing. The PDU sequence that ends in this LE GTB PDU 
shall be timed such that the LE_GTB PDU occurs the final slot of a dwell (according to what will 
be network time), and the call shall be sent on the channel that the master time station would be 
monitoring during that dwell in synchronous mode. 


Following receipt of this transmission, each station in the network shall compute the limited- 
precision time implied by the LE_GTB PDU, temporarily set its time base to this time, set its 
total time uncertainty to 70 ms and commence scanning its assigned channels in synchronous 
mode. In the following dwells, each dwell group will in turn monitor the channel that carried the 
time distribution transmission. During that dwell, the time server in each dwell group shall 
execute a Sync Check handshake with the network master time station to refine its time and set 
its time uncertainty. 


After 32 dwells have elapsed since the end of the initial LE_GTB transmission, all stations shall 
stop scanning and remain on their current calling channel. Each dwell group will be on a distinct 
channel, and the time server in each group should have completed a Sync Check handshake with 
the master time station. Each such dwell group time server shall then transmit identical 

LE_ Notification PDUs in slots 1, 2, and 3 of the dwell, followed by an LE_ GTB PDU in slot 4. 
The Slot Number field in this LE_GTB PDU shall be 4. Dwell group members shall perform 
Sync Check handshakes with their respective group time servers in the following 60 dwells, 
starting with member number 0 in the first dwell after this normal LE GTB PDU, member 
number | in the next dwell and so on. After 60 dwells, all stations shall resume scanning on their 
assigned channels. 


Breakdowns in this protocol are handled as follows: 


1. Any dwell group time server that has not received the expected 
LE_Notification/LE_GTB sequence from the master time station within 8 minutes after 
the expected startup of the time distribution protocol should initiate the late net entry 
synchronization protocol from C.5.2.7.6, calling the master time station and, if it receives 
no response after calling on all channels, calling designated alternate master time 
station(s) and other group time servers. 


2. Any dwell group member that received the initial LE_Notification/LE_GTB sequence 
from the master time station, but does not receive the expected LE_Notification/LE_GTB 
sequence from the group time server after listening for 60 dwells should attempt late net 
entry synchronization calling its dwell group time server first, followed by calls to the 
master and alternate master time stations. 


3. Any dwell group member that does not receive the initial LE_Notification/LE_ GTB 
sequence from the master time station within 10 minutes after the expected startup of the 
time distribution protocol should initiate the late net entry synchronization protocol from 
C.5.2.7.6, calling its group time server first, followed by calls to the master and alternate 
master time stations. 
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As each station achieves synchronization, it commences synchronous operation. 


C.5.3 TM_ protocol. 


C.5.3.1 Overview. 

The TM protocol is used to coordinate traffic exchanges on connections established using the 
Third Generation ALE (3G-ALE) protocol. Following the end of the ALE phase in which a 
connection is established, the stations participating in the connection enter the Traffic Set-Up 
(TSU) phase in which the TM protocol is used to establish a traffic link on which traffic can be 
delivered. 


Once a connection has been established, the stations participating in it have determined: 


1. the identities of the stations intended to participate in the connection; 
2. the connection topology: point-to-point, multicast, or broadcast; 
3. the link mode: packet or circuit (“hard link”’); 


4. the HF frequency (or “traffic channel’’) that will be used for signalling within the 
connection. 


In addition, each participating station knows whether or not it initiated the connection (even 
though stations other than the initiator do not always know which station originated the 
connection, as in broadcast connections), so that the initiating station knows it can transmit a TM 
PDU in the first transmit time-slot of the TSU phase. 

During the TSU phase, the participating stations exchange TM PDUs in order to determine: 


1. whether the connection will be used to deliver data or voice traffic, if it is a circuit 
connection; 


2. which data link protocol(s), waveform(s), and/or baseband modulation formats will be 
used to deliver traffic on the connection; 


3. the priority of the traffic to be delivered; 


4. the fine time synchronization required for the HDL and LDL protocols, on traffic links 
established for packet traffic. 


If the traffic link is a multicast circuit link (has a multicast topology), the participating stations 
initially conduct a roll-call procedure to determine which of the stations in the multicast group 
received the 3G-ALE signalling and are now present on the traffic frequency. A second roll-call 
can be conducted on the traffic link just before the traffic link is torn-down and the participating 
stations resume scanning. This allows a station sending information on a Multicast circuit link to 
know whether the intended recipients of the information were on the traffic frequency to receive 
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it, and allows the station initiating the traffic link to drop the current link and attempt to re- 
establish it if desired stations are absent from the link. 


When traffic exchanges have been completed on a traffic link, the TM protocol is used to 
coordinate the participating stations’ departure from the traffic link. 


C.5.3.2 Data object types. 
The terms defined in table C-X XXIV are used to refer to specific types of data objects in defining 
the TM protocol. 


TABLE C-XXXIV. TM data object types. 
type 
traffic type identifies a kind of traffic that can be delivered on a traffic link established using the TM protocol. The 
defined traffic types and their meanings are as follows: 
value 


HDL n HDL (HDL), n data packets per forward transmission (n = 24, 12, 6, or 3) 

LDL_n 

ANDVT Digitized voice using the ANDVT digitized voice coding method and modem waveforms 

DGTL_VOICE | Digitized voice using a non-ANDVT digitized voice coding method and/or modem 
waveform. The receiving station is assumed to be able to detect the voice coding and 
modem waveform and apply the appropriate receive processing. 

ANLG_VOICE 

SER_110 Bit-pipe data traffic delivered using the MIL-STD-188-110 serial tone modem signalling 
format. 

HQ n Bit-pipe data traffic delivered using a high-rate data modem signalling format at n bits per 
second (n = 9600, 6400, 4800, or 3200). 

SER_ 4285 Bit-pipe data traffic delivered using the STANAG 4285 serial tone modem signalling 
format. 


Note: In the TM behavior definitions, ‘pktTraf? is used as an abbreviation for a traffic type of either HDL_n 
or LDL_n, which can be delivered only on a packet traffic link, or for ‘NO_TR’ (no traffic). ‘cktTraf? is used 
as an abbreviation for any traffic type other than HDL_n or LDL _n -- i.e., any traffic type that can be 
delivered on a circuit traffic link — or for ‘NO_TR’ (no traffic). 


PKT packet traffic: refers to any traffic type that can be delivered on a packet traffic link: i.e., 
any of the HDL_n or LDL_n traffic types. Is used in contexts in which a station knows 
that a packet link is required, but not the specific type of packet traffic to be delivered on 
the link. 
circuit traffic: refers to any traffic type that can be delivered on a circuit traffic link, 
including all of the defined traffic types except HDL_n and LDL_n (which are delivered 
only on packet traffic links). Is used in contexts in which a station knows that a circuit 
link is required, but not the specific type of traffic to be delivered on the circuit link. 
no traffic: the sender has no traffic to deliver, and will await traffic from the other 
participant(s) in the traffic link. 
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C.5.3.3 Service primitives. 

Table C-XXXV describes the service primitives exchanged between the TM entity and a user 
process at TM’s upper interface. Note that there is no requirement that implementations of the 
waveforms and protocols defined in this Appendix contain precisely these service primitives; nor 
are the services primitives defined below necessarily all of the service primitives that would be 
required in an implementation of these waveforms and protocols. 


TABLE C-XXXV. TM service primitives. 


link. 
Parameters topology Identifies the topology of the traffic link being established; one of: 

P2P (point-to-point): the traffic link will contain the initiating station 
and a single called station. 
MC (multicast): the traffic link will contain the initiating station together 
with all members (or as many as possible) of a defined multicast group. 
BC (broadcast): the traffic link will contain the initiating station together 
with all other stations in the net that receive the ALE Broadcast PDUs 
used to place the broadcast call. 

The topology value must be ‘P2P’ if trafficType is any of the 3G data link 

traffic types HDL_n or LDL _n. 

value can be any of the traffic type values defined in table C-X XXIV. 


role role of the local station in the established traffic link: MASTER (initiator of 
the link) or SLAVE. 


priority priority level of the traffic (at the initiating station) for which the traffic link 
is being requested: HIGHEST, HIGH, ROUTINE, or LOW. 


addr address of the station or group of stations to be included with the local station 
in the requested traffic link: an individual or multicast address, or a null 
(ignored) address for broadcast traffic links. 
reqIntvl the duration of the time-interval through which TM should wait to receive a 
TM_REQ PDU from the initiating station before timing-out. The reqIntvl 
parameter-value is used only by slave stations in broadcast circuit links; it is 
ignored in all other cases. 
| Originator | userprocess | 
Preconditions 1. Aconnection has just been established by 3G-ALE, with this station as a participant. 
2. No traffic link is established. Le., the most recent service primitive (if any) passed 
between TM and the user process was a TM_Disconnect_Req, a TM_Disconnect_Ind, or 
a TM_Disconnect_Conf. 
TM_Connect_Ind Overview TM Connect Indication: issued to the user process to indicate that a traffic link has been 
established at the request of a remote station, with the local station as a participant. 
Parameters trafficType | Identifies the type of traffic for which the traffic link is being established; value 
can be any of the traffic type values defined in table C-XXXIV. Obtained from 
the Argument (Traffic type) field of the TM REQ PDU sent by the initiating 
station. 
priority priority level of the traffic for which the traffic link has been established: 
HIGHEST, HIGH, ROUTINE, or LOW. This value is obtained from the 
Priority field-value of the TM_REQ PDU sent by the link master station to 
initiate the establishment of the link. 
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TABLE C-XXXV. TM service primitives (continued). 
Name 


srcAddr station address of the station that initiated establishment of the link (the link 
master). Obtained from the Source Addr field-value of the TM REQ PDU sent 
by the initiating station. 


responses list of addresses of the members of the multicast group (for multicast links) 
from which a valid roll-call response was received; null (ignored) for point-to- 
point and broadcast links (on which no roll-call is performed). 
Preconditions | No traffic link is established. I.e., the most recent service primitive (if any) passed between 
TM and the user process was a TM_Disconnect_Req, a TM_Disconnect_Ind, or a 
TM_Disconnect_Conf. 
TM_ Connect | Overview TM Connect Confirm: issued to the user process by TM, to confirm that a traffic link has been 
_ Conf established as requested by a preceding TM_Connect_Req service primitive. 


Parameters respons | list of addresses of the members of the multicast group (for multicast links) from 
es which a valid roll-call response was received; null (ignored) for point-to-point and 
broadcast links (on which no roll-call is performed). 


Preconditions Either a traffic link is being established at the request of the local user process; i.e., the most recent 
service primitive passed between TM and the user process was a TM_Connect_Req; or an established 
traffic link is being reversed after successful delivery of packet data; i.e., the most recent service primitive 
passed between TM and the user process was a TM_Connect_Ind. 


TM_Disconn | Overview TM Disconnect Request: issued to TM by the user process, to request that the local station 

ect_Req cease to participate in the current traffic link, and if the local station is the link master, that the 

traffic link be terminated entirely, with all of the remaining participants leaving the traffic 

frequency (or frequencies). 
Parameters reason reason for disconnection. Value is one of: 
e RELINK: requests that the traffic link be re-established on a different channel. 

Used only on point-to-point traffic links. 
SIGN_OFF: requests that the local station sign-off a multicast or broadcast 
circuit link, without necessarily causing the link to be terminated: other 
stations may stay linked. Used only at slave stations on multicast and 
broadcast circuit links. 
ABORT: requests that the traffic link be immediately terminated. In broadcast 
or multicast circuit connections, can be issued only by the user process of the 
circuit master: the station that initiated the circuit. 
UNLINK: requests that a multicast traffic link be terminated with a final roll 
call occurring just before the link is dropped. Used only on multicast circuit 
links; can be issued only at the master station: the station that initiated the 
circuit. 


period on point-to-point circuit and multicast circuit links, the maximum amount of time 
that TM can wait for the link to become available so that the TM_TERM PDU sent 
as the station departs from the link does not collide with other traffic. After TM 


waits this amount of time, if the CLC still indicates that the link is busy, TM sends 
a TM_TERM PDU and drops the link regardless of any ongoing link activity. The 
period parameter-value is ignored (not used) on packet and broadcast circuit links. 
user process 
Preconditions | A traffic link is currently established or is being established. I.e., TM has accepted a 
TM_Connect_Req service primitive since the most recent time at which it issued a 
TM_Disconnect_Ind ora TM _Disconnect_Conf, or accepted a TM _Disconnect_Req. 
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TABLE C-XXXV. TM service primitives (continued). 


TM_Disconnect_I | Overview TM Disconnect Indication: issued to the user process to indicate that the local station has ended 
nd its participation in a traffic link for a reason other than the user process’ having issued a 
TM_Disconnect_Req primitive. 
Parameters reason reason for disconnection. Value is one of: 

e SIGN_OFF: indicates that the local station has left a traffic link due to another 
station’s having signed-off the link — the other station in a unicast link, or the 
last remaining station in a multicast or broadcast circuit of which the local 
station was master. 

ABORT: the local station has left a traffic link due to the link master station’s 
having aborted the link. 
EOM: the local station has left a packet traffic link due to successful 
completion of the packet data transfer and the absence of any packet traffic 
pending in the reverse direction. 
RELINK: the remote station has initiated a re-link operation in which the 
participating stations will attempt to re-establish the traffic link on a different 
channel, by sending a TM_TERM PDU to the local station with Reason = 
RELINK. Used only on point-to-point traffic links. 
REQ TIMEOUT: the local station has left a traffic link due to failure to 
receive a TM_REQ PDU in the time period in which one was expected. If the 
traffic link being established was a unicast link, the two stations will attempt to 
re-link. 
CONF_TIMEOUT: the local station has left a traffic link due to failure to 
receive a TM_CONF PDU in the time period in which one was expected. If 
the traffic link being established was a unicast link, the two stations will 
attempt to re-link. 
TRF_TIMEOUT: the local station has left a circuit traffic link, due to the 
CLC’s (CLC’s) having detected no traffic on the circuit link over a time 
interval equal to its traffic timeout period. 
UNLINK: the remote master station of the currently-established multicast 
circuit has requested that the circuit link be dropped after a final roll call 
(“unlink”) is performed. A TM_Disconnect_Ind service primitive with reason 
= UNLINK requests that the user process respond with a 
TM_Disconnect_Resp service primitive indicating whether the local station 
has succeeded or failed in receiving the traffic delivered on the circuit link. 
Originator | TM) 
Preconditions A traffic link is currently established or is being established. I.e., TM has accepted a 
TM_Connect_Req service primitive since the most recent time at which it issued a 
TM_Disconnect_Ind ora TM Disconnect_Conf, or accepted a TM_Disconnect_Req. 
TM_Disconnect_ | Overview TM Disconnect Response: issued to TM by the user process to acknowledge that a currently- 
Resp active multicast circuit is being “unlinked”: i.e., dropped after a final roll call is performed. 
Parameters Positive or negative acknowledgement of having received the traffic delivered on 
the multicast circuit. Possible values are 

e ACK: the traffic delivered on the multicast circuit was received successfully 
(with the user process determining what counts as “success’’) 

e NAK: the traffic delivered on the multicast circuit was not detected or received 
containing (an excessive quantity of) errors. 

Boolean: if TRUE, TM will wait on the traffic channel to hear the unlink roll call 

responses from the other circuit participants. Otherwise, the station will wait only 

long enough to transmit its own roll call response in its unlink roll call time slot, 
and will immediately afterward return to 3G-ALE scanning. 
Origination = — 1] INV 1) a 
Preconditions . Amiulticast circuit link is presently active. 
TM has just issued a TM_Disconnect_Ind service primitive to the user process with reason 
= UNLINK. 
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TABLE C-XXXV. TM service primitives (continued). 


TM_Disconnect_ ieee | 


Parameters 


TM Disconnect Confirm: issued to the user process by TM to acknowledge that a currently- 

pee lee traffic link is being dropped as a result of a TM_Disconnect_Req service primitive. 

reason The reason for which the traffic link is being dropped. Possible values and their 
meanings are the same as for the reason parameter of the TM_Disconnect_Req 
service primitive, as described above. 


responses | list of responses to an optional unlink roll-call performed at the conclusion of a 
multicast circuit connection, in which each response is in the form of an ordered 
pair (indAddr, ackNak), where indAddr is the address of a station whose roll call 
response was heard, and ackNak is the Reason field-value of the TM_TERM PDU 
sent as the station’s response: UNL_ACK or UNL_NAK. The responses 
parameter has a value only when a multicast circuit link has been concluded with 
an unlink roll call. The list of responses can be incomplete for either of two 
reasons: 

1. ataslave station, the user process has requested that the station remain in the 
circuit link only long enough to transmit its own roll call response, by setting 
the watch parameter of its TM_Disconnect_Resp primitive to FALSE. In this 
case, the reason parameter has the value UNLINK; and responses are not 


included in the list from those stations whose roll call time slots fall after the 
local station’s time slot. 
at either the master station or a slave station, the user process may have cut 
short the station’s participation in the roll call, by issuing a 
TM_Disconnect_Req service primitive while the roll call is in progress. In 
this case, the reason parameter-value will be ABORT at the master station, or 
SIGN_OFF at a slave station; the response list will include only responses 
received before the TM_Disconnect_Req was accepted. 
The responses parameter is shown in the state diagrams only where it is used: 
where a multicast circuit link is being dropped with a concluding unlink roll call 
operation. 

a (eee 
fee at ag er ee Be Oe 
TM Suspend Request: issued to TM by the user process, to suspend the current multicast circuit 

link. This primitive can be issued by the user process at the station which has initiated a 
multicast circuit link, when the responses to a just-completed roll call indicate that not all 
members of the multicast group are present in the circuit link. In response to the 
TM_Suspend_Reg service primitive, the TM entity sends a TM_TERM PDU with reason = 
SUSPEND to hold the stations that answered the roll call on the traffic channel, then repeats the 
3G-ALE multicast calling process in order to bring as many as possible of the remaining stations 
into the multicast circuit link. 


(none) 


user 
process 


A multicast circuit link initiated by the local station is currently active. I.e., since any other 
exchange of TM service primitives, TM has issued a TM_Connect_Conf service primitive to the 
user process whose responses parameter identifies those multicast group member stations which 
responded to the most recent multicast circuit roll call. 

TM Resume Request: issued to TM by the user process, to cause the current multicast circuit 
link to be resumed after it has been suspended by means of a TM_Suspend_Req service 
primitive. In response to the TM Resume_Req, TM sends a TM_ REQUEST PDU on the traffic 
channel, to initiate an additional roll call and determine which of the multicast group members 
are now present on the traffic channel. 


|(none) fp 


user 
process 


A multicast circuit link is currently suspended. 
2 Since the multicast circuit link was suspended by means of a TM_Suspend_Req PDU, an 
additional 3G-ALE multicast call has been completed. 
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C.5.3.4 PDUs. 

The sub-sections of this section describe the PDUs exchanged between a TM entity and its 
remote peer entities. All TM PDUs have the common format and contents shown in table 
C-XXXVI. Behavioral descriptions of the TM protocol refer to three kinds of PDUs: TM_REQ, 
TM_CONF, and TM_TERM. These PDUs all have the format shown in table XXXVI, and are 
distinguished from one another by the values of their Type fields: 


e a“TM REQ PDU” is a TM PDU having Type = TM_ REQUEST (0) 
e a“TM CONF PDU” is a TM PDU having Type = TM_CONFIRM (1) 
e a“TM_ TERM PDU” is a TM PDU having Type = TM_TERM (2) 


The field-values of each TM PDU are transmitted in order of their occurrence in table XXXVI, 
starting with the protocol field. The bits of each field-value are transmitted in order of 
significance, starting with the most significant bit. 


All of the TM PDUs are sent and received using the burst waveform BW1 described in section 
C.5.1.4. Each outgoing PDU is used as the Payload parameter value fora BW1_ Send service 
primitive as described in table C-IV; each incoming PDU is received as the value of the Payload 
parameter of a BW1_Receive service primitive (see table C-XX XVII). 


The TM entity at each station remains active while the station is exchanging voice or data traffic 
with other stations on an established traffic link, so as to be ready to drop the link on request. On 
traffic links established for packet traffic delivered using the HDL protocol (C.5.2) or the LDL 
protocol (C.5.5), the user process can terminate the data link transfer and use the next data link 
transmission time slot in either direction — 1.e., the time slot for the xDL_DATA or the 
xDL_ACK PDU — to instead send a TM_TERM PDU (by issuing a TM_Disconnect_Req 
primitive) as many times as will fit within the data link PDU time-slot. This means that while a 
data link transfer is in progress, each station must be simultaneously attempting to demodulate 
TM_TERM PDUs conveyed by the BW1 waveform as it is attempting to demodulate and receive 
data link signalling conveyed by BW2, BW3, or BW4. Similarly, on a circuit link, each station 
must attempt to detect and demodulate TM_ TERM PDUs conveyed by the BW1 waveform at all 
times when the station is not transmitting. 
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TABLE C-XXXVI. TM PDU format. 


Field name Size Values Description 
(bits) 


001, (fixed) | distinguishes TM PDUs from HDL_ACK and HDL_EOM PDUs 


Priority 2 In all TM_REQ and some TM_CONF PDUs (i.e., TM PDUs having Type = TM_REQUEST or 
TM_CONFIRM), indicates the priority level of the traffic (if any) that the sender of the PDU 
intends to send on the traffic link once it is established. In TM_CONF PDUs, this field is used 
only when the Argument field value refers to one of the High-Rate ((HDL_n’) or LDL (‘LDL_n’) 
traffic types as shown in table C-XXXVII. The field-value is set to 3 (LOW) in all other 
TM_CONF PDUs and in all TM_ TERM PDUs, and must be ignored by the receiver. 

0 __| HIGHEST: highest priority 


HIGH 
ROUTINE 
_3._| LOW: lowest priority 


Dest Addr 11 any address of the station to which this PDU is being sent. Dest Addr can be the 
individual address of a single intended recipient station (abbreviated ‘indAddr’ 
below), a multicast address designating a multicast group (‘MCaddr’), or all 
ones on a broadcast traffic link (‘BCaddr’) (see note). When the destination 
address is a multicast address, the lowest-order five bits of the address 
(corresponding to the dwell group number in an individual address) shall be all 
ones. 


Source Addr 11 any address of the station that is sending this PDU. Is always the station address of 
a single station — never a multicast or broadcast address. 


Type 3 Type of PDU, indicating its role in the TM protocol. Note that the state diagrams and other 
materials refer to, for instance, a “TM_ REQ PDU”; this is a TM PDU whose Type field value is 0 
(TM_REQUEST). 

TM_REQUEST: A PDU with Type = TM_REQUEST is sent in order to request 
that a traffic link be established between the station sending the TM REQUEST 
and the other stations specified by the PDU’s destination address. 

1 TM_CONFIRM: A PDU with Type = TM_CONFIRM is sent in response to a 
received TM REQUEST PDU, to confirm the sender’s readiness to participate 
in a traffic link. 

TM_TERM: a PDU with Type = TM_TERM is sent in order to terminate the 
station’s participation in a traffic link (during or after link establishment), and 
when sent by the link master, to terminate the link as a whole. 


oe stake variant field whose usage and meaning depend on the value of the Type field; see TABLE 
XXXVII. 


CRC 12 any 12-bit Cyclic Redundancy Check (CRC) computed across the remaining 36 bits 
of each TM PDU, using the generator polynomial 
x4 xX + K+ Ko 4 K+ KO + XP4+ X74 XK! 41, 
and the procedure described in C.4.1. 


NOTE: The destination address has no significance on broadcast links; this field is set to all-ones purely by convention. The all- 
ones address vaule is not a reserved broadcast address, and hence can also be used as an individual or multicast 
address. 
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Type field Value Field 
name 


TM_REQUEST Traffic 
or Type 
TM_CONFIRM 


| | 


NOTE: Whether the traffic has been received successfully, and what this means, are determined by the user process and not by TM. 
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TABLE C-XXXVII. Argument field values. 


Indicates the type of traffic that the sender expects to send or receive on the traffic link once it is established. 
Each argument field-value represents one of the traffic type values defined in TABLE C-XXXIV. Ina 
TM_REQUEST PDU, the Traffic Type field-value serves to stipulate the type of traffic that will be delivered 
on the traffic link. The sender of a TM_ CONFIRM PDU places in this field the value of the Traffic Type field 
in the TM_REQUEST PDU it has recently received; in this case, the field-value serves as an acknowledgement 
of the traffic type specified in the TM REQUEST. 


PO 
pT 
P20 
E00: > 0: 
PA 
pS 
PO 
ANDVT 


ne 
9 | DGTL_VOICE 


ANLG_VOICE 
SER_110 
HQ_9600 
HQ_6400 

Indicates the reason why the sending station is terminating its participation in the traffic link, and the intended 

result of its doing so. 

0 (“ABORT”) Immediately terminate the traffic link, with all participating stations leaving the 
traffic frequency (-ies) assigned to the link. Reason = ABORT indicates nothing 
about any measures that may be taken to resume any data transfer that may have 
been in progress. 

1 (RELINK’”) Immediately terminate the traffic link, with all participating stations leaving the 
traffic frequency (-ies) assigned to the link. Reason = RELINK indicates that the 
user process will attempt to resume the data transfer, possibly on a different 
frequency or frequencies. 

2 (“SIGN_OFF’’) The station sending the TM_TERM PDU is departing the multicast circuit link, of 
which it is not the master. If two or more stations remain on the link, they may 
continue to exchange traffic. 

3 ““UNLINK”) Is sent by the initiator of a multicast circuit link, to cause the link to be torn-down 
after a final roll call is performed. 

4 “UNL_ACK”) Is sent by a participant in a multicast circuit link in response to a TM_TERM PDU 
with Reason = UNLINK, to indicate that the station has successfully received all 
traffic sent on the multicast circuit (see note). 

5 (“SUNL_NAK”) Is sent by a participant in a multicast circuit link in response to a TM_TERM PDU 
with Reason = UNLINK, to indicate that the station is still present in the multicast 
circuit, but has not received all traffic sent on the multicast circuit successfully. 

6 (“SUSPEND”) Suspends the current multicast circuit link while the link initiator repeats the 3G- 
ALE multicast call in order to retrieve as many as possible of the multicast group 
members that were found to be absent in the most recent roll call. Stations 
receiving the TM_TERM PDU with Reason = SUSPEND are expected to remain 
on the traffic channel for a time period sufficient to allow the link initiator to 
complete the 3G-ALE multicast call, return to the traffic channel, and send a 
TM_REQ PDU to start another roll call. 
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C.5.3.5 Protocol behavior. 
The following sections define the behavior of the TM protocol: 


e C.5.3.5.1 identifies and defines the events to which the TM entity responds; 


e C.5.3.5.2 identifies and defines the actions taken by the TM entity in response to these 
events; 


e C.5.3.5.3 describes the data items used and maintained by a TM entity; 


e C.5.3.5.4 provides state diagrams and a state transition table specifying the behavior of 
the TM entity in terms of these events, actions, and data items; and 


e C.5.3.5.5 provides additional information on the timing characteristics of TM protocol 
behavior. 


C.5.3.5.1 Events. 

Table C-X XXVIII defines the events to which the TM entity responds. The event names are 
used in the state diagrams or state transition tables in C.5.3.5, which define the behavior of the 
TM protocol. Some event names refer to the receipt of PDUs from the TM entity at a remote 
station; in these cases, either the PDU definition in C.5.3.4 or the ‘description’ field of the table 
entry describes the manner in which the arrival of a PDU is accomplished through TM’s 
accepting one or more service primitives from lower-layer entities at the local station. The prefix 
‘Ry’ in the name of an event indicates that the event is the receipt of a PDU from the remote 
station. The prefix ‘D:’ indicates that the event is the TM entity’s accepting a service primitive 
from a higher-layer entity (the primitive is passed ‘downward’), while the prefix ‘U:’ indicates 
that the event is the TM entity’s accepting a service primitive from a lower-layer entity (the 
primitive is passed ‘upward’). Event names are used in the state diagrams and the transition 
table precisely as shown here, with the following exception: italicized words in the event names 
shown here are substitution variables for which explicit parameter- or field-values are substituted 
when these event names are used in the state diagrams and the transition table. 
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TABLE C-XXXVIII. TM events. 


ConfirmTimeout A TM _CONF PDU was not received in the time period in which it was 
expected, in the two-way handshake performed to establish a point-to-point 
traffic link for packet or circuit traffic, as indicated by a timeout of 
ConfirmTimer. 

D:TM_Connect_Req A TM _Connect_Req service primitive was received from the user process, with 

(topology, trafficT ype, role, the indicated values for the topology, trafficType, role, addr, and reqIntvl 

addr, reqIntvl) parameters. In the state diagrams and state transition table, 

e ‘topology’ is replaced by ‘P2P’ (point-to-point), ‘MC’ (multicast), or ‘BC’ 
(broadcast), indicating the topology of the traffic link being established 
‘role’ is replaced by ‘MASTER’ or ‘SLAVE’, where the link master is the 
station initiating the traffic link 
‘trafficType’ is replaced by one of the traffic type values defined in table C- 
XXXIV. The values ‘PKT’ and ‘CKT”’ are used whenever role = SLAVE, 
since the slave station does not yet know the specific type of traffic that is to 
be delivered on the traffic link (as this information is not conveyed by 3G- 
ALE). ‘pktTraf? is used as an abbreviation for any of the HDL_n or LDL _n 
traffic types which can be delivered on a packet traffic link; ‘cktTraf? is used 
for any traffic type other than HDL_n or LDL_n, which can be delivered on 
a circuit traffic link. 

‘addr’ is replaced by either ‘indAddr’ (the remote station participating in a 
packet or point-to-point circuit link), ‘MCaddr’ (the address of the called 
multicast group), or ‘BCaddr’ (the all-ones broadcast address). Note that 
addr is ignored whenever topology = BC; although an all-ones broadcast 
value is transmitted in TM PDUs, this address value has no significance. 
‘reqintvl’’ is used only at slave stations participating in broadcast circuit 
links. The value of reqIntvl is based on the Countdown field-value of the 
received LE BROADCAST PDU. 

D:TM_Disconnect_Req A TM _Disconnect_Req service primitive was received from the user process, 

(reason) having the indicated value, or one of the provided list of values, as its reason 

D:TM_Disconnect_Req parameter. ‘reason’ may be either a single parameter value (e.g., “ABORT”) or 

(reason, period) a list of two or more possible reason values separated by ‘pipe’ characters (‘|’) 
(e.g., “ABORT|RELINK’”). An event name containing the word ‘reason’ instead 
of a specific parameter-value applies to any TM_Disconnect_Req service 
primitive containing any value for the reason parameter. 


The value of the period parameter determines the maximum length of time that 
TM will wait for the link to become available before sending a TM_TERM 
PDU, if the link is busy (as determined by CLC) at the time the 
TM_Disconnect_Req service primitive is accepted from the user process. The 
period parameter is shown on the state diagrams only in those situations in 
which it is used: 1.e., on circuit traffic links after the link has been established 
(and hence could be busy). In all other contexts, the period parameter-value is 
ignored. 


D:TM_ Suspend Req A TM Suspend. Req service primitive was received from the user process. 
D:TM_ Resume Req ATM Resume Req service primitive was received from the user process. 


DropTimeout The time limit limiting the period through which TM can wait for the traffic link 
to become idle before sending a TM_TERM PDU in response to a 
TM_Disconnect_Req has been exceeded, as indicated by a timeout of 
DropTimer. 
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TABLE C-XXXVIII. TM events (continued). 
Description 
EndOfMCRollCall Indicates that the time period in which stations participating in a multicast 
circuit link are expected to transmit their roll-call responses has ended, as 
indicated by the RollCallTimer. 


EndOfUnlink Indicates that the time period in which stations participating in a multicast 
circuit link are expected to transmit their unlink roll-call responses has ended, as 
indicated by the UnlinkRollCallTimer. 


MyRCSlot Indicates that the time-slot allocated to the local station for transmission of its 
roll call response has arrived, as indicated by the RollCallTimer. See C.5.3.5.5 
for a specification of the timing of the multicast roll-call operation. Roll call 
time slots are assigned to multicast group member stations in the following 
manner: 

The individual addresses of the multicast group member stations are placed 
in a list. 

If the link master (the station that initiated the link) is a member of the 
multicast group, its individual address is removed from the list (see note). 
The list of addresses is sorted by increasing dwell group number, and, for 
stations in the same dwell group, by increasing member number (so that, for 
instance, {group #4, member#5} precedes {group #5, member #2}, and 
{group #5, member #2} precedes {group #5, member #4}). 

The station whose address is first in the list is assigned the first roll call slot 
(the slot immediately following the transmission of the TM REQUEST 
PDU that initiated the roll call), the one whose address is second gets the 
second slot, and so forth. 


transitions leaving the current state. 
labels on transitions leaving the current state. 
R:TM_COMF (pktTraf, A TM _CONF PDU was received from the station with individual address 
srcAddr) srcAddr, confirming establishment of the traffic link requested by a preceding 
R:TM_COMNF (cktTraf, TM_REQ PDU. The Traffic Type field value (represented by ‘pktTraf? or 
srcAddr) ‘cktTraf’) should be identical to that of the TM REQ PDU sent most recently 
by the local station; received TM_ CONF PDUs in which this is not the case 
shall be ignored. If the requested traffic link is a multicast circuit link, then the 
TM_CONF PDU is a roll call response, which should be received in the correct 
roll call time-slot of the station having srcAddr as its individual address; any 
TM_ CONF PDU having an incorrect source address for the roll call time slot in 
which it was received shall be ignored. On point-to-point links, the TM CONF 
PDU should be received immediately following the transmission of the 
TM_ REQ PDU to which it is a response; otherwise, a ConfirmTimeout occurs. 
R:TM_REQ (pktTraf, A TM_REQ PDU was received from the station with individual address 
srcAddr) srcAddr, requesting establishment of a traffic link for delivery of the traffic type 
R:TM_REQ (cktTraf, represented by ‘pktTraf? (HDL_n or LDL _n traffic) or ‘cktTraf? (circuit traffic: 
srcAddr) i.e., neither HDL_nnor LDL_n). 
R:TM_REQ (cktTraf, A TM_REQ PDU was received from the station with individual address 
srcAddr, MCaddr) srcAddr, requesting establishment of a multicast circuit link containing members 
of the multicast group having address MCaddr, for delivery of the traffic type 
represented by ‘cktTraf? (circuit traffic). 
R:TM_TERM (reason) A TM_TERM PDU, having RELINK, ABORT, or SIGN_OFF as the value of 
its reason parameter, was received from the remote station participating in a 
point-to-point link. 
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TABLE C-XXXVIII. TM events (continued). 


R:TM_TERM (ABORT, 
srcAddr) 


R:TM_TERM (SIGN_OFF, 
srcAddr) 


R:TM_TERM (SUSPEND, 
srcAddr) 


R:TM_TERM (UNLINK, 
srcAddr) 


R:TM_TERM (ackNak, 
srcAddr) 


RequestTimeout 


ReversalTimeout 


U:CLC_Avail_ Ind 


U:CLC_Busy_Ind 


U:CLC_ Idle Ind 


J:xDL_Rev_Ind 


U:xDL_Send_Conf 


A TM_TERM PDU was received from the station with address ‘srcAddr’, with 
reason = ABORT: the sending station is dropping a currently-established circuit 
link of which it was the master participant. 

A TM_TERM PDU was received from the station with address ‘srcAddr’, with 
reason = SIGN_OFF: the sending station is signing-off a currently-established 
circuit link in which it was a slave participant. 

A TM_TERM PDU was received from the station with address ‘srcAddr’, with 
reason = SUSPEND: the sending station is suspending a currently-established 
multicast circuit link of which it was the master participant, while it repeats the 
multicast call so as to attempt to include additional stations in the circuit link. 

A TM_TERM PDU was received from the station with address ‘srcAddr’, with 
reason = UNLINK: the sending station is dropping a currently-established 
multicast circuit link in which it was the master station, and requesting that the 
stations present in the circuit respond to an unlink roll-call as they leave the 
circuit. 

A TM_TERM PDU was received from the station with address ‘srcAddr’, with 
reason = UNL_ACK or UNL_NAK: the sending station is leaving the current 
multicast circuit link, and indicating that it did (if reason = UNL_ACK) or did 
not (if reason = UNL_NAK) successfully receive the traffic transmitted on the 
circuit. 

A TM _REQ PDU was not received in the time period in which it was expected, 
in the course of an attempt to establish a traffic link, as indicated by a timeout of 
RequestTimer. 

A TM_REQ PDU was not received in the time period in which it was expected, 
in the course of an potential packet traffic link reversal, as indicated by a 
timeout of ReversalTimer. 

A CLC_Avail_Ind service primitive was received from the CLC, indicating that 
the traffic link is available for new traffic (i.e., not busy). 

A CLC _Busy_Ind service primitive was received from the CLC, indicating that 
the traffic link is busy (i.e., not available for new traffic). 

A CLC_Idle_Ind service primitive was received from the CLC, indicating that a 
traffic timeout occurred: no outgoing or incoming traffic was detected on the 
circuit link over a time period equal to the traffic timeout interval. 

An HDL Rcv_ Ind or LDL_Rev_Ind service primitive was received from, 
respectively, the High-Rate or LDL, indicating that the data link has just 
successfully completed an incoming datagram transfer. 

An HDL_Send_Conf or LDL_ Send_Conf service primitive was received from, 
respectively, the High-Rate or LDL, indicating that the data link has just 
successfully completed an outgoing datagram transfer. 


NOTE: It is considered unnecessary for the link master to respond to the roll call, since it has indicated its 


presence by sending the original TM_ REQUEST. No roll call response time slot is assigned to the link master at 
all, since assigning one and leaving it unused could cause a listening station to erroneously declare the channel 
unused (and hence available) if it were to listen on the channel during the unused time slot. 


C.5.3.5.2 Actions. 


Table C-XXXIX defines the actions which the TM entity can perform. The action name is used 
in the state diagrams and/or state transition tables used below to define the behavior of the TM 
protocol. Some action names refer to sending PDUs to the TM entity at a remote station; in these 
cases, the PDU definition in C.5.3.4 or the ‘description’ field of the table entry describes the 
manner in which sending of the PDU is accomplished by issuing one or more service primitives 
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to subordinate entities at the local station. Action names are used in the state diagrams and the 
transition table precisely as shown here, with the following exception: italicized words in the 
action names shown here are substitution variables for which explicit parameter- or field-values 
are substituted when these action names are used in the state diagrams and the transition table. 


TABLE C-XXXIX. TM actions, 


D:CLC_Active Req Issue a CLC_Active_Req service primitive to the CLC, requesting that it begin 
monitoring and arbitrating access to the newly-established circuit link. 

D:CLC_Idle_Req Issue a CLC_Idle_Req service primitive to the CLC, requesting that it cease 
monitoring and arbitrating access to the circuit link. 

D:CLC_Set_Priority (prio) Issue a CLC_Set_Priority service primitive, giving it a new priority value for 
pending outgoing traffic (if any) for the current circuit link. Where the word 
‘prio’ occurs in place of an explicit value for the prio parameter, this indicates 
that the prio parameter has assigned to it the value of the priority parameter of 
the TM_Connect_Req primitive that caused the current traffic link to be 
established. 


InitRollCall Initialize (empty) RollCallResponses; initialize and start RollCallTimer. 
InitUnlink Initialize (empty) UnlinkResponses; initialize and start UnlinkRollCallTimer. 


InitWaitForConfirm Initialize ConfirmTimer to start timing the time-interval in which an incoming 
TM_ CONFIRM PDU is expected in the establishment of a packet or point-to- 
point circuit link. The timeout interval duration is Tgw) + 2T propmax + Tawiene + 
2TBwiproc following the emission of the last sample of an outgoing 
TM_REQUEST PDU, where the ‘T,,’ duration constants are as defined in 
C.5.3.5.5. 


InitWaitForRequest Initialize RequestTimer to start timing the time-interval in which an incoming 
TM_ REQUEST PDU is expected in the establishment of a packet or point-to- 
point circuit traffic link. The timeout interval duration is Tyne + 2T sug + 


Tprop,max + Tawi + Tpwiproc following the end of the 3G-ALE time slot in which 
the LE HANDSHAKE PDU was transmitted or received, where the ‘T,’ 
duration constants are as defined in C.5.3.5.5. 

InitWaitForRequest (MC) Initialize RequestTimer to start timing the time-interval in which an incoming 
TM_ REQUEST PDU is expected in the establishment of a multicast circuit 
traffic link. The timeout interval duration is Tat wait meast + Ttune + 2Tsug + 
Tprop,max + Tawi + Tpwiproc following the end of the 3G-ALE slot in which the 
LE HANDSHAKE PDU specifying the traffic channel for the circuit link was 
received, where Tyra wait mcast iS an initial set-up parameter, and the remaining 
‘T,’ duration constants are as defined in C.5.3.5.5. 

InitWaitForRequest (SUSPEND) _ | Initialize RequestTimer to start timing the time-interval in which an incoming 
TM_ REQUEST PDU is expected after an established multicast circuit traffic 
link has been suspended. The timeout interval duration is 2T gw) + Tpwiproc + 
Tirat wait_mcast 2T welt Tine 2T sug Tprop,max Hts Tawi + TBwiproc following the 
instant in which the last sample of the TM _TERM(SUSPEND) PDU was 
received, where Tyraf wait meast iS an initial set-up parameter, and the remaining 
‘T,’ duration constants are as defined in C.5.3.5.5. 

InitWaitForRequest (reqIntvl) Initialize RequestTimer to start timing the time-interval in which an incoming 
TM_ REQUEST PDU is expected in the establishment of a broadcast traffic 
link. The value of reqIntvl is supplied by the user process as the reqIntvl 
parameter-value of the TM _Connect_Req service primitive, and is based on the 
countdown field-value of the received LE BROADCAST PDU. 
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TABLE C-XXXIX. TM actions (continued). 


InitWaitForReversal Initialize ReversalTimer to start timing the time-interval in which an incoming 
TM REQUEST PDU is expected at the former sending station in a packet 
traffic link reversal. The timeout interval duration is Tgw; + Tpwiproc following 
the instant at which the arrival of the first sample of an xDL_ACK PDU would 
have been expected if the preceding data link transfer had not been already 
completed. In this case, if a request timeout occurs, TM assumes that the 
remote station did not attempt to reverse the packet traffic link; it is up to the 
user process at the remote station to set-up a new traffic link (via 3G-ALE and 
TM) to deliver any packet traffic it has, if an attempted packet link reversal 
fails. 


MarkAbsent (srcAddr) Record in RollCallResponses the fact that no roll call response was received 
NY | peaneomioonbaeerena 


MarkPresent (srcAddr) Record in RollCallResponses the fact that a roll call response was received 
from the station with address srcAddr. 
MarkReverseTrafficPending Set ReverseTrafficPending to TRUE. 


none No action. 

RecordUnlinkResponse (ackNak, | Add an entry to UnlinkResponses representing a received unlink roll call 

srcAddr) response from the station whose individual address is srcAddr, and ackNak is 
the Reason field value of the response (TM_TERM) PDU: UNL_ACK or 
UNL_NAK. 

S:TM_COMF (pktTraf, srcAddr) Send a TM_CONF (“Confirm”) PDU with destAddr = the individual address of 

S:TM_COMF (cktTraf, srcaddr) the station that initiated the traffic link being established by sending a 
TM_REQ PDU, and trafficType = the traffic type announced in the TM REQ 
PDU. ‘pktTraf’ represents an announced packet traffic type (HDL_n or 
LDL_n); ‘cktTraf’ represents an announced circuit traffic type (neither HDL_n 
nor LDL_n). 

S:TM_CONMF (cktTraf, MCaddr) Send a TM_CONF PDU in the local station’s roll call time slot., with destAddr 
= the multicast address of the multicast group for which the circuit link is being 
established, and trafficType equal to the circuit traffic type value announced in 
the TM_ REQ PDU sent by the link master to initiate the roll call operation. 

S:TM_REQ (trafficT ype, Send a TM_REQ PDU requesting establishment of a traffic link, with 

destAddr) trafficType = the type of traffic to be delivered on the requested link, and 
destAddr identifying the stations intended to participate in the link. In the state 
diagrams and transition table, ‘pktTraf? is used to refer to any form of packet 
traffic delivered by either the High-Rate ((HDL_n’) or the LDL ((LDL_n’); 
‘cktTraf’ is used to refer to any traffic type that can be delivered on a circuit 
link: i.e., any type other than HDL_nor LDL _n. For circuit links, the type of 
destination address depends on whether the requested link is a point-to-point, 
multicast, or broadcast link; this is signified in the state diagrams and transition 
table by the use of the abbreviations ‘indAddr’, ‘MCaddr’, and ‘BCaddr’. 


369 


MIL-STD-188-141B 
APPENDIX C 


TABLE C-XXXIX. TM actions (continued). 


S:TM_TERM (reason, addr, Send one or more TM_TERM PDUs having the indicated values for the 
howMany) Reason and Dest Addr fields. addr is the station address of the remote 

participant in a point-to-point link (circuit or packet), the multicast address of 
the multicast group participating in a multicast circuit link, or the all-ones 
broadcast address. The howMany term (which does not refer to a PDU field) 
indicates how many times the TM_TERM PDU is to be sent: 
once, if no explicit howMany value is provided; 
three times, if howMany = ‘3x’; and 
as many times as possible within a High-Rate or LDL forward transmission 

interval, if howMany = ‘nx’: 

once, for traffic type HDL_3 or HDL _ 6; 

three times, for traffic type HDL_12; 

seven times, for traffic type HDL_ 24; 

once, for traffic type LDL_64 or LDL_128; 

two times, for traffic type LDL_256; and 

five times, for traffic type LDL_512. 
When ‘reason’ occurs in the state diagrams or transition table in place of an 
explicit Reason field-value, this indicates that this field is to be given the value 
of the Reason parameter of the TM_Disconnect_Req service primitive most 
recently received from the user process. When ‘ackNak’ is shown in the reason 


position, this indicates that the Reason field-value is to be either UNL_ACK or 
UNL_NAK, depending on whether the station successfully received the traffic 
transmitted on the multicast circuit which is now being dropped. In this case, 
the Reason field-value should be the same as the ackNak parameter-value of 
the TM_Disconnect_Resp service primitive just accepted from the user 


process. 


ScheduleAbort Set ScheduledAbort to TRUE. 
ScheduleSignoff Set ScheduledSignoff to TRUE. 


SetDropTimeout (period) Set DropTimer to time out and generate a DropTimeout event after an interval 
of duration period has elapsed. 


SetupUnlink (ackNak, watch) Record whether the traffic transmitted on the multicast circuit now being 
dropped was received successfully, as indicated by the ackNak parameter-value 
of the TM_Disconnect_Resp service primitive just accepted from the user 
process. Also record whether the local station is to remain on the traffic 
channel long enough to hear all of the unlink roll call responses from the 
participants in the multicast circuit. 

U:TM_Connect_Conf Issue a TM_Connect_Conf service primitive to the user process, confirming 

U:TM_Connect_Conf (responses) | establishment of the requested traffic link, of which the local station is now link 
master. If the established link is a multicast circuit link, the ‘responses’ 
parameter identifies the stations from which roll call responses were received; 
this parameter is omitted when the link is a point-to-point or broadcast link. 
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TABLE C-XXXIX. TM actions (continued). 


U:TM_Connect_Ind (trafficType, | Issue a TM Connect_Ind service primitive to the user process, indicating that a 

srcAddr, responses) traffic link has been established of which the local station is a non-master 
participant. The trafficType parameter identifies the type of traffic for which 
the traffic link is being established, and should habe the same value as the 
Argument (Traffic Type) field of the TM REQ PDU that was sent by the 
station initiating the traffic link. The srcAddr parameter is the individual 
address of the station that initiated the traffic link. If the established link is a 
multicast circuit link, the responses parameter identifies the stations from which 
roll call responses were received; this parameter is omitted when the link is a 
point-to-point or broadcast link. 

U:TM_Disconnect_Conf (reason) | Issue a TM_Disconnect_Conf service primitive with its reason parameter 

U:TM_Disconnect_Conf (reason, | having the indicated value to the user process. Where the word ‘reason’ occurs 

responses) in place of an explicit value for the reason parameter, this indicates that the 
reason parameter has assigned to it the value of the reason parameter of the 
TM_Disconnect_Req primitive to which the TM_Disconnect_Conf primitive is 
aresponse. The responses parameter is present only if the link being dropped 
is a multicast circuit link and if an unlink roll call has been performed; in this 
case, the value of the responses parameter is a list of the unlink roll call 
responses received by the local station. 

U:TM_Disconnect_Ind (reason) Issue a TM_Disconnect_Ind service primitive with its reason parameter having 
the indicated value to the user process. Where the word ‘reason’ occurs in 
place of an explicit value for the reason parameter, this indicates that the reason 
parameter has assigned to it the value of the ‘reason’ field of a just-received 
TM_TERM PDU. 


C.5.3.5.3 Data. 

Table C-XL defines the data items used and maintained by the TM entity, including buffers, 
counters, timers, configuration parameters, and so forth. These data items are referred to by the 
names assigned to them here, in the definitions of TM events and actions presented in the 
preceding sections. These data items are used in this specification only as expository devices; it 
is not required for compliance that an implementation contain these data items in the forms 
described here. 
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TABLE C-XL. TM data items. 


Timer timing the period in which receipt of a TM_ CONF PDU is expected in response to 
a TM_REQ PDU just sent. 

Timer timing the interval TM waits for the traffic link to become available (no longer 
busy) as indicated by CLC, so that TM can send a TM_TERM PDU in response to a 
TM_Disconnect_Req. 

Boolean condition variable: is TRUE if and only if CLC has declared the current circuit 
link to be busy (without since then having declared it to be non-busy — 1.e., available for 
new traffic). 


RequestTimer Timer timing the period in which receipt of a TM_ REQ PDU is expected, when the local 
station is a slave participant in a connection which has just been established by 3G-ALE. 
The timeout period varies depending on the traffic link topology; see the descriptions of 
the InitWaitForRequest() actions for further details. 


ReversalTimer Timer timing the period in which receipt of a TM_REQ PDU is expected, when the local 
station has just completed an outgoing data link transfer on a packet traffic link, and is 
waiting for an indication that the remote station has data link traffic to send on the traffic 
link. 

ReverseTrafficPending | Boolean condition variable; when TRUE, indicates that the non-master participant in a 
packet traffic link has packet traffic to send to the link initiator, and hence that the link 
direction will be reversed once delivery of the link initiator’s packet traffic has been 
completed. 

RollCallResponses List of the system addresses of stations intended to participate in the current multicast 


circuit link (multicast group members) from which valid roll call responses have been 
received. 


RollCallTimer Timer timing each station’s participation in the roll call performed in establishing a 
multicast circuit link. Provides two time signals (interrupts) to the local station: one when 
it is time for the local station to send its own roll call response, the other when the time 
interval for all roll call responses by all participating stations has expired. 

ScheduledSignoff Boolean condition variable; when TRUE, causes the local station (non-master participant 
in a multicast circuit link) to send a TM_TERM PDU signing-off from the circuit link as 
soon as the roll call currently in progress is completed. 

ScheduledAbort Boolean condition variable; when TRUE, causes the local station (master of a multicast 
circuit link) to send a TM_TERM PDU dropping the circuit link as soon as the roll call 
currently in progress is completed. 

UnlinkResponses List of responses to the optional unlink roll-call performed at the conclusion of a 
multicast circuit connection, in which each response is in the form of an ordered pair 
(indAddr, ackNak), where indAddr is the address of a station whose roll call response 
was heard, and ackNak is the Reason field-value of the TM_TERM PDU sent as the 
station’s response: UNL_ACK or UNL_NAK. 

UnlinkRollCallTimer Timer timing each station’s participation in the optional roll call that can be performed 
just before a multicast circuit linkis dropped. Provides two time signals (interrupts) to the 
local station: one when it is time for the local station to send its own unlink roll call 
response (if any), the other when the time interval for all unlink roll call responses by all 
participating stations has expired. 


C.5.3.5.4 Behavior definition. 

For the reader’s convenience, two equivalent representations of the behavior of the TM protocol 
are provided in this section: the state transition table in table C-XLI, and the state diagrams 
figures C-21 through C-25. Due to the complexity of the state-machine behavior, it has been 
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found necessary to represent this behavior on four different state diagrams. Note that the Idle 
state shown on all four diagrams is the same single state: each diagram depicts only a subset of 
the transitions entering and leaving the Idle state. 


Both the state diagrams and the transition table specify the behavior of the TM entity in terms of 
the events defined in C.5.3.5.1 and the actions defined in C.5.3.5.2. The conditions gating 
certain transitions are specified in terms of the data items defined in C.5.3.5.3. 


In the state diagrams, each state transition is labeled with an event, an optional condition, and 
zero or more actions. This indicates that the state transition occurs whenever the event occurs 
and the condition obtains (is TRUE), causing the associated actions to be performed. In the 
diagram, 


e the name of each event is shown in square brackets preceded by the letter ‘E’; 


e the description of each condition is shown in square brackets preceded by the letter ‘C’; 
and 


e the names of the actions associated with a transition are shown in square brackets 
preceded by the letter ‘A’. 


Where a transition is labeled with two or more events, this indicates that the transition occurs 
whenever any of the events occurs. 


In the state diagrams and the state transition table, text within text boxes or braces (“{}”’) is 
commentary and not part of the formal state machine definition. 
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FIGURE C-23. TM state diagram: multicast circuit (master). 
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FIGURE C-24. TM state diagram: multicast circuit (slave). 
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TABLE C-XLI. TM state transition table. 


Idle D:TM_Connect_Req (P2P, S:TM_REQ (pktTraf, indAddr)+ 
Con 

D:TM_ Connect Req (P2P, S:TM_ REQ (cktTraf, indAddr)+ 
Cat 


D:TM_Connect_Req (P2P, Wait for P2P Circuit 
CKT, SLAVE, indAddr) Request 
, . InitRollCall Responses 


D:TM_Connect_Req (MC, 
cktTraf, MASTER, MCaddr) 
D:TM_Connect_Req (MC, 
CKT, SLAVE, MCaddr) 
D:TM_Connect_Req (BC, 
cktTraf, MASTER) 
D:TM_Connect_Req (BC, 
CKT, SLAVE, BCaddr 
reqIntvl) 


Wait for | R:TM_CONF (pktTraf, 
Packet srcAddr) 


ee ee | 

| 

a 

ConfirmTimeout S:TM_TERM (RELINK, indAddr, Idle 
R:other nx)+ 
U:TM_Disconnect_Ind 

(CONF_TIMEOUT) 

| 

| 

a 

ee 

el 


S:TM_REQ (cktTraf, BCaddr)+ Linked as BC Master 
U:TM_Connect_Conf 


InitWaitForRequest (reqIntvl) Wait for BC Request 


U:TM_Connect_Conf Linked as Packet 
Master 


D:TM_Disconnect_Req S:TM_TERM (reason, indAddr, nx)+ | Idle 
(ABORT | RELINK) U:TM_Disconnect_Conf (reason) 
R:TM_TERM (reason) U:TM_Disconnect_Ind (reason) 


other none Wait for Packet 
Confirm 

InitWaitForReversal Wait for Packet 
Request 
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Packet 
Master 


D:TM_Disconnect_Req 
(ABORT | RELINK) 
R:TM_TERM (reason) 


other 
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aa | 
oneness ee ee 
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Wait for | R:TM_REQ (pktTraf, srcAddr) 
Packet 
Request 


D:TM_Disconnect_Req 
(SIGN_OFF | RELINK) 
R:TM_TERM (reason) 


RequestTimeout 


ReversalTimeout 
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TABLE C-XLI. TM state transition table (continued). 


a: a 
Request 
Linked as | U:xDL_Rev_Ind NOT Reverse | U:TM_Disconnect_Ind (EOM) 
Packet Traffic 
Slave Pending 
U:xDL_Rcev_Ind Reverse S:TM_REQ (pktTraf, sreAddr)+ Wait for Packet 
Traffic InitWaitForConfirm Confirm 
Pending 


Pe Nite ee ES ra ee ii 
D:TM_Disconnect_Req S:TM_TERM (reason, indAddr)+ Idle 
{SIGNOFF REIN) || UMD Contam 
_R:TM_TERM (reason) |_| UTM _Disconnect_Ind(reason) | Idle 
D:TM_Connect_Req (P2P, MarkReverseTrafficPending Linked as Packet Slave 
putagwastexecagiy | [wes [init 

i= =iihothier te eS = i = = WSs = 

| 


other none Linked as Packet Slave 
Wait for | R:TM_CONF (cktTraf, 
P2P srcAddr) 
Circuit 
Confirm 


U:TM_Connect_Conf+ Linked as P2P Circuit 
D:CLC_Active_ Req (P2P) Master 


D:TM_Disconnect_Req 
(ABORT) 


S:TM_TERM (ABORT, indAddr, 
3x)+ 

U:TM_Disconnect_Conf (ABORT) 
S:TM_TERM (RELINK, indAddr, 
3x)+ 

U:TM_Disconnect_Ind 
(CONF_TIMEOUT) 


R:TM_TERM (reason) 


ConfirmTimeout 
R:other 


Linked as | R:TM_TERM (reason) 
P2P 

Circuit 

Master 


U:TM_Disconnect_Ind (reason)+ 
D:CLC_Idle_Req 


D:TM_Disconnect_Req NOT S:TM_TERM (reason, indAddr)+ 
(ABORT | RELINK) LinkBusy D:CLC_Idle_Req+ 
U:TM_Disconnect_Conf (reason) 


a 
(ABORT | RELINK, period) SetDropTimeout (period) Circuit, Master 
U:CLC_Idle_Ind {traffic S:TM_TERM (ABORT, indAddr)+ Idle 
timeout} U:TM_Disconnect_Ind 

(TRF_TIMEOUT) 
Master 
geass 
Master 
8 Ee eee 
Master 
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TABLE C-XLI. TM state transition table (continued). 


Wait to U:CLC_Avail_Ind S:TM_TERM (reason, indAddr)+ 
Drop DropTimeout D:CLC_Idle_Req+ 
P2P U:TM_Disconnect_Conf (reason) 


Circuit, 
other none Wait to Drop P2P 
Circuit, Master 


Master 
Wait for | R:TM_REQ (cktTraf, srcAddr) S:TM_CONF (cktTraf, sreAddr)+ Linked as P2P Circuit 
P2P U:TM_Connect_Ind (cktTraf, Slave 
Circuit srcAddr)+ 
Request D:CLC_ Active Req (P2P) 

RequestTimeout S:TM_TERM (RELINK, indAddr)+ 

R:other U:TM_Disconnect_Ind 

(REQ TIMEOUT) 


D:TM_Disconnect_Req S:TM_TERM (reason, indAddr)+ Idle 
(SIGN_OFF | RELINK) U:TM_Disconnect_Conf (reason) 
R:TM_TERM (reason) |__| U:TM_Disconnect_Ind (reason) Idle 


other none Wait for P2P Circuit 


Request 
Linked as | D:TM_Disconnect_Req NOT S:TM_TERM (reason, indAddr)+ 
P2P (SIGN_OFF | RELINK) LinkBusy D:CLC_Idle_Req+ 
Circuit U:TM_Disconnect_Conf (reason) 
Slave 


U:CLC_Idle_Ind {traffic S:TM_TERM (SIGN_OFF, 
timeout} indAddr)+ 

U:TM_Disconnect_Ind 

(TRF_TIMEOUT) 
D:TM_Disconnect_Req i D:CLC_Set_Priority (TM)+ Wait to Drop P2P 
(SIGN_OFF | RELINK, SetDropTimeout (period) Circuit, Slave 
period) 


U:CLC_Busy_Ind MarkLinkBusy Linked as P2P Circuit 
Slave 

U:CLC_Avail_Ind MarkLinkAvail Linked as P2P Circuit 
Slave 


Linked as P2P Circuit 
Slave 


Wait to U:CLC_Avail_Ind S:TM_TERM (reason, indAddr)+ 
Drop DropTimeout D:CLC_Idle_Req+ 

P2P U:TM_Disconnect_Conf (reason) 
Circuit, 

Slave 


other none Wait to Drop P2P 
Circuit, Slave 
Wait for | EndOfMCRollCall NOT U:TM_Connect_Conf (responses)+ Linked as MC Master 


MC Roll Scheduled D:CLC_Active_Req (prio) 
Call Abort 


Response 
R:TM_COMF (cktTraf, MarkPresent (srcAddr) Wait for MC Roll Call 
srcAddr) Responses 


Ss 
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TABLE C-XLI. TM state transition table (continued). 


ea cc Pc 
(ABORT) Responses 
cee ee Ne ee ee 
Responses 
Abort S:TM_TERM (ABORT, MCaddr, 3x) 
(Ee (ea | PPPS] (RR De ee 
Linked as | R:TM_TERM (SIGN_OFF, other stations | MarkAbsent (srcAddr) Linked as MC Master 
MC srcAddr) present 


Master 
R:TM_TERM (SIGN_OFF, NOT other MarkAbsent (srcAddr)+ Idle 
srcAddr) stations U:TM_Disconnect_Ind (SIGN_OFF)+ 
present S:TM_TERM (ABORT, MCaddr)+ 

D:CLC_Idle_Req 
D:TM_Disconnect_Req NOT S:TM_TERM (ABORT, MCaddr)+ Idle 
(ABORT, period) LinkBusy D:CLC_Idle_Req+ 

U:TM_Disconnect_Conf (ABORT) 
(ABORT, period) SetDropTimeout(period) Circuit, Master 
U:CLC_Idle_Ind {traffic U:TM_Disconnect_Ind Idle 
timeout} (TRF_TIMEOUT)+ 

S:TM_TERM (ABORT, MCaddr) 


D:TM_Suspend_Req 


S:TM_TERM (SUSPEND, MCaddr, Retrieving Absent 
3x) Members 


D:TM_Disconnect_Req NOT S:TM_TERM (UNLINK, MCaddr)+ Unlink MC Circuit, 
(UNLINK, period) LinkBusy D:CLC_Idle_Req+ Master 
InitUnlink 


D:TM_Disconnect_Req D:CLC_Set_Priority (TM)+ 
(UNLINK, period) SetDropTimeout (period) 

Linked as MC Master 
ees Ne gt Ee Ne ee ti ines te 
Retrieve D:TM_Resume_Req S:TM_REQ (cktTraf, MCaddr)+ Wait for MC Roll Call 

Absent InitRollCall Responses 
Members 


U:CLC_Avail_Ind Ps MarkLinkAvail Linked as MC Master 


D:TM_Disconnect_Req 
(ABORT) 


ae 
fal 
S:TM_TERM (ABORT, MCaddr, 
3x)+ U:TM_Disconnect_Conf 
(ABORT) 
ae Retrieve Absent 
Members 
ye pee 
S:TM_TERM (ABORT, MCaddr)+ Idle 
D:CLC_Idle_Req+ 
Circuit, U:TM_Disconnect_Conf (ABORT) 
Master 
a Wait to Drop MC 
Circuit, Master 
a ee 
RecordUnlinkResponse (ackNak, Unlink MC Circuit, 
srcAddr) Master 


R:TM_TERM (ackNak, 
srcAddr) 

Circuit, 

Master 
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TABLE C-XLI. TM state transition table (continued). 


EndOfUnlink U:TM_Disconnect_Conf (reason, Idle 
D:TM_Disconnect_Req responses) 
ie 

_ SSS eS 


Te to U: tee _ Avail_Ind ———-; TM_TERM SRT MCaddr)+ INOS MC Circuit, 
Unlink, DropTimeout D:CLC_Idle_Req+ Master 
Master ea 


se —____- eee Wes ele Unlik, Maver Unlink, Master 


Wait aE R:TM_REQ TRO srcAddr, 3397 Wait See MC Roll Call 
MC MCaddr) Responses, Slave 
Request 
a 
R:other (REQ_ TIMEOUT) 
famonye ee |e ee | 
(SIGN OFF) 


— other Poker s—<—ssSY pone | Wait for MC Request | for MC Request 
are eed || ere ey Pe ee ee! 
Wait for | EndOfMCRollCall NOT U:TM_Connect_Ind (cktTraf, srcAddr, | Linked as MC Slave 
MC Roll Scheduled responses)+ 
Call Signoff D:CLC_Active_ Req (ROUTINE) 
Response 
s, Slave 


emigre eee eee 
srcAddr) Responses, Slave 
eee ee eee eel 
Responses, Slave 
nn ne. 
oi OFF) Responses, Slave 
Responses, Slave 
Se — U:TM_Disconnect_Conf Idle 
Signoff (SIGN_OFF)+ 
S:TM_ TERM (SIGN_OFF, MCaddr) 
ek ee ee ee es ee oe 


“Taxed 7) RIMTERM RTM TERM SIGNOFF ; MarkAbsent (srcAddr) Linked as MC Slave 
srcAddr) 


D:TM_Disconnect_Req S:TM_TERM (SIGN_OFF, 
(SIGN_OFF, period) i MCaddr)+ 
D:CLC_Idle_Reqt+ 
U:TM_Disconnect_Conf 
(SIGN_ OFF) 
(SIGN_OFF, period) SetDropTimeout (period) Circuit, Slave 
R:TM_TERM (ABORT, srcAddr is | U:TM_Disconnect_Ind 
srcAddr) link (ABORT)+ 
master's D:CLC_Idle_Req 
address 
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TABLE C-XLI. TM state transition table (continued). 


U:CLC_Idle_Ind {traffic U:TM_Disconnect_Ind Idle 
timeout} (TRF_TIMEOUT) + 
-U:CLC Busy Ind | | MarkLinkBusy | Liked as MC Slave _| 
U:CLC_AvailInd | | MarkLinkAvail | Liked. as MC Slave _| 
eager eee eee eee lee eee 
srcAddr) 
cay | ietaine  | Sie | 
srcAddr) InitSlaveUnlink Slave 
| 


pother | mone | Linked as MC Slave 
Wait to U:CLC_Avail_Ind 
Drop MC | DropTimeout 
Circuit, 
Slave 


S:TM_TERM (SIGN_OFF, 
MCaddr)+ 
D:CLC_Idle_Req+ 
U:TM_Disconnect_Conf 
(SIGN_OFF) 


SetupUnlink (ackNak, watch) Unlink MC Circuit, 
MC (ackNak, watch) Slave 


Circuit, 
Slave 
srcAddr) srcAddr) Slave 
WatchUnlink | S:TM_TERM (ackNak, MCaddr) 
Resps Slave 


MyUnlinkSlot NOT Watch S:TM_TERM (ackNak, MCaddr)+ Idle 
UnlinkResps U:TM_Disconnect_Conf (UNLINK, 
responses) 
EndOfUnlink U:TM_Disconnect_Conf (reason, Idle 
responses) 


D:TM_Disconnect_Req 
(SIGN_OFF) 

none Unlink MC Circuit, 
Slave 


S:TM_TERM (ABORT, BCaddr)+ Idle 
U:TM_Disconnect_Conf (ABORT) 


Linked as BC Master 
U:TM_Connect_Ind (cktTraf, Linked as BC Slave 
srcAddr)+ 
D:CLC_Active_ Req (ROUTINE) 

{CLC used only for traffic timeout} 


Unlink D:TM_Disconnect_Resp 


Linked as | D:TM_Disconnect_Req 
BC (ABORT) 
Master 


Wait for | R:TM_REQ (cktTraf, srcAddr) 
BC 
Request 
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TABLE C-XLI. TM state transition table (continued). 


RequestTimeout U:TM_Disconnect_Ind Idle 
R:other (REQ TIMEOUT) 


D:TM_Disconnect_Req U:TM_Disconnect_Conf (SIGN_OFF) | Idle 
(SIGN_OFF) 


-—— ote poe ppene_ Waller BC Rewer 
BC Slave (SIGN OFF) U: T™ Disconnect | Conf (SIGN_OFF) 
R:TM_TERM (ABORT, srcAddr is U:TM_Disconnect_Ind (ABORT)+ Idle 
srcAddr) link master's | D:CLC_Idle_ Req 
address 
a 
incu, HORE TIMEOUT) TIMEOUT) | 


‘none = =§©———..__- | Linked as BC Slave | as BC Slave 


C.5.3.5.5 Timing characteristics. 

The protocol timing characteristics vary depending on which kind of traffic link is being 
established. The sub-sections of this section describe the timing characteristics applying to 
establishment and execution of, respectively, point-to-point packet traffic links, point-to-point 
circuit links, and multicast circuit links. 


Table C-XLII gives definitions of time intervals used in presenting the protocol timing 
characteristics. 
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TABLE C-XLII. Protocol time-intervals. 


Interval # 32 # 48 # PSK Duration Description 
Tb. | = Symbol times) (ms., approx.) 


Tie | | 1920) | 800) Duration of 3G-ALE slot. 


Le _— Duration of 3G-ALE dwell. 


128 53.33|LE sync uncertainty guard interval 


| 80.00) 00|maximum propagation ‘maximum propagation delay = 


—— 33/BWO processing time Se last sample is 
received) 
66.67|BW 1 encoding time (prior to emission of first 
sample) 
Tew 3136 1306.67|BWI1 transmission duration 
(TLC+preamble+data) 
Tgwiproc 133.33|BW1 processing time (after last sample is 
received) 
Tpweenc 22 704 293.33|BW2 encoding time (prior to emission of first 
sample) 
Tpw2 2 5+20n 304+960n 126.67+|BW2 transmission duration -- n packets per 
(n*400.00)|transmission (n = 3, 6, 12, or 24) 
Tpw23) 2 65 3184 1326.67|BW2 transmission duration (3 packets per 
transmission) 
Tpw26) 2 125 6064 2526.67|BW2 transmission duration (6 packets per 
transmission) 
Twa) 2 245 11824 4926.67|BW2 transmission duration (12 packets per 
transmission) 
Tpw2(24) 2 485 23344 9726.67|BW2 transmission duration (24 packets per 
transmission) 
Tpwoproc 220.00|BW2 processing time (after last sample is 
received) 
Pea iy 66.67|BW3 encoding time (prior to emission of first 
sample) 
ie a as 373.33+|BW3 transmission duration (preamble+data) — n 
(n*13.33)|payload bytes per transmission (n = 64, 128, 256, 
ca 1226.67|BW3 transmission duration (preamble+data) — 64 
payload bytes per transmission 
Ss 2080.00|BW3 transmission duration (preamble+data) — 
128 payload bytes per transmission 
284 9088 3786.67|BW3 transmission duration (preamble+data) — 
256 payload bytes per transmission 
Tpw3(512) 540 17280 7200.00|BW3 transmission duration (preamble+data) — 
512 payload bytes per transmission 
Tpw3proc 5 160 66.67|BW3 processing time (after last sample is 
received) 


Tpwaenc 5 160 66.67|BW4 encoding time (prior to emission of first 
sample) 
Tews = | 48) 1536 640.00|BW4 transmission duration (TLC+data) 
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TABLE C-XLII. Protocol time-intervals (continued). 
Interval # 32 # 48 # PSK Duration Description 
— Frames |Symbol times| (ms., approx.) 
66.67|BW4 processing time (after last sample is 
received) 


= Tyg + 2TBwi + 
E a sirises + Tawiene. 
Time from start of TM REQUEST PDU to start 
of first HDL_ DATA PDU. Trrep, HDL — 2Tawi + 


2T prop,max 2s 2T Bwiproc a, Tpwienc + Tpw2ene: 


Time from start of TM CONFIRM PDU to start 
of first HDL_ACK PDU. Tocrra, HDL — Tawi a 
TBwiproc ae 2T prop,max Tpwzenc Tawa) tT BW2proc 
+ Tawienc- 


Period of HDL protocol. Tupi = Taweenc + 
Tawa(n) +2T prop,max + Tpw2proc + Tawiene + Tawi + 


Time from start of TM REQUEST PDU to start 
of first LDL_DATA PDU. Trrep, LDL — 2Taw1 or 


QT pop miax es 2T Bwiproc + Tpwienc + Tpw3enc: 


Time from start of TM CONFIRM PDU to start 
of first LDL_ACK PDU. Tocrra, LDL(n) = Tawi a 
TBwiproc + 2T prop,max Tpw3enc Taw3(n) + T BW3proc 
+ Tpwaenc- 


Trin) Period of LDL protocol. Tipim = Taw3enc + 


Taw3n) + 2T prop,max + Tpw3proc Tpwa4enc Tawa 
Twaproe: 


ke dee of TM roll call slot. Ty. son tm = Tawienc 
te Tew + 2* Tprop max + Tswiproc 


Tctenc 2400 1000.00|MIL-STD-188-110 serial tone (see note) modem 
transmit startup delay: the permitted time interval 
between presentation of the first bit of data to the 
modem for modulation (when RTS is asserted), 
and emission of the first time-sample of the 
modem preamble. Note that this delay is not 
required for encoding per se, since MIL-STD- 
188-110 modems typically start emitting the 
modem preamble simultaneously with encoding 
the first bit of traffic data. The modem startup 
delay defined here is a characteristic of modem 
implementations rather than of the MIL-STD- 
188-110 standard. 
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TABLE C-XLII. Protocol time-intervals (continued). 


Interval # 32 # 48 # PSK Duration Description 
Frames | Frames |Symbol times} (ms., approx.) 


Tctpre 15 480 200.00) Duration of a single period of the Mil-Std-188- 
110A serial tone modem preamble: the minimum 
portion of the modem preamble that must be 
received and processed to successfully detect and 
acquire sync with an incoming modem 
transmission. 


Ttproc 15 480 200.00| Mil-Std-188-110A serial tone modem acquisition 
processing delay: the processing time required 
following receipt of the last sample of a 200 ms. 
Preamble period, before the receiving modem 
can declare modem signal presence based on 
having acquired the preamble. 


NOTE: Timing analyses for circuit links assume that these links are used for bit-pipe delivery of data using 
MIL-STD-188-110 serial tone modems; the timings used for delivery of other kinds of traffic on circuit links are the 
same. 


C.5.3.5.5.1 Point-to-point packet link. 
This section will first provide a description of point-to-point packet link timing. Following this, 
point-to-point packet link timing requirements will be given. 


C.5.3.5.5.1.1 Point-to-point packet link timing description. 
The contents of this section are for informational purposes only. 


The TM phase of the point-to-point packet link is considered to begin at the end of the 3G-ALE 
time-slot in which the LE COMMENCE PDU (see note) is transmitted. Since only a two-way 
TM handshake is performed, it is not possible for both stations to estimate the propagation delay 
between them. Instead, in each direction, the TM handshake signalling is used to establish the 
timing for all subsequent signalling in that direction. In the forward direction, the first 
xDL_DATA PDU (High-Rate or Low-Rate) is sent at a fixed time interval known a priori to both 
stations, following the transmission of the TM REQUEST PDU. Likewise, in the reverse 
direction, the first xDL_ACK PDU is sent at a fixed time interval known a priori to both stations, 
following the transmission of the TM CONFIRM PDU. The entire process is depicted on figure 
C-26 through figure C-30, and analyzed in further detail below, using the HDL protocol for the 
purpose of illustration. 


Note: I.e., an LE HANDSHAKE PDU in which the Command field’s value is “Commence 
Traffic”. 


The linking activity proceeds as follows: 


e First, an LE handshake is performed. This handshake establishes a link time reference, 
Tink, for both the Master and the Slave. This time reference is defined as the start of the 
LE slot immediately following the LE slot in which the LE COMMENCE PDU was 
transmitted. If TOD offset exists between the Master and the Slave (1.¢e. Tdetarop # 9), 
Tiink Will not be the same for Master and Slave, and so we introduce individual Think 
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values for each station, Think Master ANd Think slave. Figure C-27 through figure C-30 show 
examples of Téeitarop having a non-zero value, and thus Think Master  Tiink,Slave- Tiink,Master 
and Think, slave can differ by no more than Tyup. 


e Next, Master and Slave are given an opportunity to change to the traffic channel and 
tune, if necessary. This opportunity lasts Tiune seconds. 


e Next, a TM handshake is performed. As was done for LE timing, the Master begins 
emission of the TM REQUEST PDU Tug seconds into the TM time slot. (The reason 
for this is shown on figure C-30.) Unlike CM handshakes, the response (in this case the 
TM_CONFIRM) is always emitted a fixed duration after reception of the first TM PDU 
of the handshake. As shown in the figures, this fixed response latency is Tpwiproc + 
Tgwienc. Combining this fixed response latency with the duration of the two BW1 
waveforms, a second processing delay for the Master to process the response, the sync 
uncertainty guard time, and worst-case propagation delay gives the duration of Tr Master 
as defined in table C-XLI and as shown in the figures. Note that Tra Master 1S fixed in 
duration, but Trsiave 18 Not. TTM,slave 18 equal to Tro Master - Tdeltatop + Tprop. The fact 
that Tr siave is variable does not complicate matters for the Slave station, however, 
since the TM REQUEST and the first forward transmission of the data link protocol are 
separated by a fixed amount of time, Trtrp, Hpi. As a result, the Slave need only 
measure the time of arrival of the TM REQUEST PDU to know when to expect the 
first forward transmission of the data link protocol and thus Tro siave. (TT slave 
terminates Tgw2enc Seconds prior to the expected arrival of the first forward 
transmission.) Similarly, the Master need only measure the time of arrival of the 
TM_CONFIRM PDU to know when to expect the first HDL_ACK PDU, as these two 
events will be delayed by Tctraq), HDL. 


e Next, the data link protocol executes a succession of forward transmission / 
acknowledge handshakes. These handshakes occur with a period of Tupi@). Topi) 1S 
designed to account for waveform encoding and processing delays, and for worst-case 
propagation delay. Typ is defined in table C-II. Typrm) depends on the size of the 
forward transmission as established in the TM handshake. Note that the data link 
protocol time slots of the Slave are delayed Tprop with respect to the data link protocol 
time slots of the Master. 


e Finally, the data link protocol concludes when the Master issues HDL_EOM PDU(s) (as 
many as can be concatenated without exceeding Tpwam)). If reverse traffic is pending, 
the Slave issues a TM REQUEST PDU starting at the same time it would have issued 
an HDL_ACK PDU, the roles of Master and Slave reverse, and the timing proceeds as 
just described. 


A similar analysis defines the timing structure for point-to-point packet traffic links using the 
LDL protocol, with the following substitutions: 


e TBW2enc is replaced by TBW3enc 
e TBW2(n) is replaced by TBW3(n) 
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e TBW2proc is replaced by TBW3proc 

e TBWlenc is replaced by TBW4enc 

e TBW1 is replaced by TBW4 

e TBW!Iproc is replaced by TBW4proc 

e THDL(n) is replaced by TLDL(n) 

e TRTFD, HDL is replaced by TRTFD, LDL 

e TCTFA(n), HDL is replaced by TCTFA(n), LDL 


C.5.3.5.5.1.2 Point-to-point packet link timing requirements. 
The following requirements apply to point-to-point packet link timing: 


1. Stations shall reckon the start of a link as the start of the 3G-ALE slot immediately 
following the slot in which the LE COMMENCE PDU was transmitted. 


2. For Tune Seconds after the start of the link, stations shall change to the traffic channel, if 
necessary, and tune, if necessary. 


3. The Master shall begin emission of the TM REQUEST PDU Ttune + Tsug seconds after 
the start of the link. 


4. The Slave shall begin emission of its response TM PDU Tpwiproc + Tawienc Seconds after 
the end of the TM REQUEST PDU as observed by the Slave. 


5. The Master shall begin emission of the first data link protocol HDL_ DATA PDU Tptrp, 
upi seconds after emission of the TM_ REQUEST PDU began. Thereafter, the Master 
shall begin emissions of HDL_DATA PDUs Tupi) seconds after the emission of the 
previous HDL_DATA PDU began. 


6. The Slave shall begin emission of the first data link protocol HDL_ACK PDU Tctraqmy, 
upi seconds after emission of its response TM PDU began. Thereafter, the Slave shall 
begin emissions of HDL_ACK PDUs Typr) seconds after the emission of the previous 
HDL_ACK PDU began. 


7. The Master shall begin emission of the first HDL_EOM PDU Typiq) seconds after the 
emission of the previous HDL_DATA PDU began. 


8. Ifreverse traffic is pending, the Slave shall begin emission of the TM REQUEST PDU 
Tuprn) Seconds after the emission of the previous HDL_ACK PDU began. At this point 
the roles of Master and Slave reverse, and point-to-point packet link timing requirements 
4-7 apply. 
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The Master shall begin emission of the first data link protocol LDL_DATA PDU 

Trrep, LoL seconds after emission of the TM REQUEST PDU began. Thereafter, the 
Master shall begin emissions of LDL_DATA PDUs Tip) seconds after the emission of 
the previous LDL_DATA PDU began. 


The Slave shall begin emission of the first data link protocol LDL_ACK PDU Tctrany, 
Lo Seconds after emission of its response TM PDU began. Thereafter, the Slave shall 
begin emissions of LDL_ACK PDUs T pi) seconds after the emission of the previous 
LDL_ACK PDU began. 


The Master shall begin emission of the first LDL_EOM PDU Trprj) seconds after the 
emission of the previous LDL_ DATA PDU began. 


If reverse traffic is pending, the Slave shall begin emission of the TM REQUEST PDU 
Trprm Seconds after the emission of the previous LDL_ACK PDU began. At this point 
the roles of Master and Slave reverse, and point-to-point packet link timing requirements 
4 and 9-11 apply. 
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Packet Traffic Link Timing 


T 0 


deltaTOD ~ T 
CTFA(n), HDL 


T prop = ™ prop.max TLink, Master. RTFD, HDL 


| 


slot TM, Master 


TE_COM [_TWREQUEST_] FDL_DATAM) 


T BW2enc 
T BW1 proc 


plop 7 prop. 
Tprop 


TBwtenc 


dbltaTOD Tgetatoo]} T aettaron] T 


deltaTOD Tew1 Proc, BW2enc T ENE | 


TE_CALL|[TE_cOM TM_REQUEST TM_CONFIRM HDL_DATAn) HDL_ACK HDL_ACK(ny 
4 sf 


slot slot Ttune TM, Slave HDL(n) 


i. 7 
| RTFD, HDL 


T 


TE 
Link, Slave CTFA(n), HDL 


CTFA(n), HDL 


my RTFD, HDL 
Master "TM, Master 


HDL_EOM TM_REQUEST TM_CONFIRM 


Tawi Proc 


T prop 


HDL_ACK HDL_EOM HDL_DATA(n) [- FOLACK 7] 


THD 


Packet Traffic Link terminates upon 
HDL_EOM reception if no reverse 
traffic is pending. 


FIGURE C-26. Point-to-point packet link timing example for Taettarop =0. Tprop = Tprop,max. 
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aren HDL 


TM. Master 
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FIGURE C-27. Point-to-point packet link timing example for Taettarop = -Tsug: Tprop = Tprop,max. 
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Packet Traffic Link Timing 
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FIGURE C-28. Point-to-point packet link timing example for Taettarop = Tsug. Tprop = Tprop,max. 
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FIGURE C-29. Point-to-point packet link timing example for Taettarop = -Tsug, Tprop = 0. 
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FIGURE C-30. Point-to-point packet link timing example for Taecttarop = Tsug. Tprop = 0. 
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C.5.3.5.5.2 Point-to-point circuit links. 
This section will first provide a description of point-to-point circuit link timing. Following this, 
point-to-point circuit link timing requirements will be given. 


C.5.3.5.5.2.1 Point-to-point circuit link timing description. 
The contents of this section are for informational purposes only. 


Figure C-31 provides an example point-to-point circuit link. The linking activity proceeds as 
follows: 


e First, an LE handshake is performed. See the section on point-to-point packet link 
timing for further explanation. 


e Next, Master and Slave are given an opportunity to change to the traffic channel and 
tune, if necessary. This opportunity lasts Tyne seconds. 


e Next, a TM handshake is performed. This handshake is identical to that performed for 
point-to-point packet links. The Slave is able to determine when to expect the start of 
the Master’s transmission based on when it receives the TM REQUEST PDU from the 
Master (the Master’s transmission starts -Tgw1 - Tsug + Trm Master + Tctenc after the end of 
the TM_ REQUEST PDU as observed by the Slave). 


e Finally, the Master transmits its message. 


C.5.3.5.5.2.2 Point-to-point circuit link timing requirements. 
The following requirements apply to point-to-point circuit link timing: 


1. Stations shall reckon the start of a link as the start of the 3G-ALE slot immediately 
following the slot in which the LE COMMENCE PDU was transmitted. 


2. For Ttune Seconds after the start of the link, stations shall change to the traffic channel, if 
necessary, and tune, if necessary. 


3. The Master shall begin emission of the TM REQUEST PDU Tiune + Tsug seconds after 
the start of the link. 


4. The Slave shall begin emission of its response TM PDU Tpwiproc + Tawienc seconds after 
the end of the TM REQUEST PDU as observed by the Slave. 


5. The Master shall begin transmission of its message Tiune + TrmMaster + Terence Seconds 
after the start of the link. 
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Point-to-point Circuit Link 
Timing Example 
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FIGURE C-31. Point-to-point circuit link timing example. 
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C.5.3.5.5.3, Multicast circuit link. 
This section will first provide a description of multicast circuit link timing. Following this, 
multicast circuit link timing requirements will be given. 


C.5.3.5.5.3.1 Multicast circuit link timing description. 

The contents of this section are for informational purposes only. Figure C-32 shows an example 
multicast circuit link involving a Master and 3 Slaves. The linking activity for this example 
proceeds as follows: 


e First, an LE handshake is performed. This handshake establishes a link time reference, 
Tiink, for both the Master and the Slaves. This time reference is defined as the start of 
the LE slot immediately following the LE slot in which the LE COMMENCE PDU was 
transmitted. 


e Next, Master and Slaves are given an opportunity to change to the traffic channel and 
tune, if necessary. This opportunity lasts Tine seconds. 


e =Next, a TM roll-call handshake is performed. The roll-call handshake begins with a 
two-way handshake between the Master and Slave | which is identical to the two-way 
handshake performed for point-to-point links. The remaining Slaves determine roll call 
slot timing based on when they receive the TM REQUEST PDU from the Master (the 
first roll call slot starts -Tgwi - Tsug + Tro Master after the end of the TM REQUEST 
PDU as observed by each Slave). Each roll call slot Tye stot; rm Seconds in duration. This 
roll call slot timing is designed to allow Slaves the time required to process a PDU 
arriving in the roll call slot immediately preceding the Slave’s own roll call slot. (See 
figure C-32. Observe that Slave 3 is given Tgwiproc Seconds to process the preceding 
PDU.) 


e Finally, the multicast is transmitted by the Master Tcrene seconds after the end of the last 
roll call slot. 


C.5.3.5.5.3.2 Multicast circuit link timing requirements. 
The following requirements apply to multicast circuit link timing: 


1. Stations shall reckon the start of a link as the start of the 3G-ALE slot immediately 
following the slot in which the LE COMMENCE PDU was transmitted. 


2. For Ttune Seconds after the start of the link, stations shall change to the traffic channel, if 
necessary, and tune, if necessary. 


3. The Master shall begin emission of the TM REQUEST PDU Tiune + Tsug seconds after 
the start of the link. 


4. Slave | shall begin emission of its response TM PDU Tgwiproc + Tawienc Seconds after the 
end of the TM REQUEST PDU as observed by Slave 1. 
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5. Slaves 2 through n, where n is the number of members of the multicast group, shall begin 
emission of their respective response PDUs 2*Tpwiproc + 2* TBwienc + Tawi + 2*Tprop,max 
+ (m-2)*T ¢ slots rm Seconds after the end of the TM REQUEST PDU as observed by the 
Slave, where m is the position of the Slave in the multicast group (e.g. m= 2 for Slave 
PAY 


6. If, following the roll call, the Master elects to proceed with the multicast, the Master shall 
begin the multicast Tine + Tro Master + (1-1)*T rc stot: rm + Terence seconds after the start of 
the link. Otherwise, if the Master elects to transmit TM protocol PDU(s), the Master 
shall begin emission of such PDUs Tiune + Tro Master + (0-1)*T re stot: rm + Tawiene Seconds 
after the start of the link. Again, n is the number of members in the multicast group. 
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Multicast Circuit Link 
Timing Example 
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\ 
Slave 2, co-located with Slave 1 and thus having the same roll call 
slot timing as Slave 1, emits its TM_CONFIRM PDU in the first roll 
call slot. 


FIGURE C-32. Multicast circuit link timing example. 
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C.5.4 HDL protocol. 


C.5.4.1 Overview. 

The HDL is used to provide acknowledged point-to-point delivery of datagrams from a 
transmitting station to a receiving station across an already-established HF link, with selective 
retransmission (ARQ) of data received in error. The datagram passed to the HDL for delivery is 
a finite-length ordered sequence of 8-bit data bytes (octets). The HDL protocol is best suited to 
delivering relatively large datagrams under good to fair HF channel conditions. By contrast, the 
LDL protocol described in section C.5.5 provides better performance for all datagram lengths 
under fair to very poor HF channel conditions, and under all channel conditions for short 
datagrams. 


C.5.4.2 Data object types. 
The terms defined in table C-XLIII are used to refer to specific types of data objects in defining 
the HDL protocol. 


TABLE C-XLIII. HDL data object types. 


datagram an ordered sequence of 8-bit data bytes (octets) of length d/, where 1 < d/l < 7,634,944 (equal to 
(233 * 32,768) — 233 payload data bytes per data packet, and 32,768 data packets per 


datagram). 


data segment an ordered sequence of 8-bit data bytes (octets) that occur consecutively within a datagram, of 
length s/ where | < s/ < 233. 


sequence number | a 17-bit data object having the format defined in table C-XLVI, which indicates the position 
occupied by a data segment within a datagram, and, when the data segment includes the last 
data byte of the datagram, the number of bytes of payload data from the datagram in the data 
segment. 


data packet the combination of a data segment with the sequence number indicating its position within a 
datagram. If the data segment is of length less than 233 bytes (because it includes the last data 
byte of the datagram), a sequence of null data bytes (of value zero) is appended to the data 
segment so as to extend it to length 233 in constructing the data packet, and the value of the 


sequence number indicates how many of the 233 bytes in the extended data segment contain 
payload data from the datagram. 

a sequence of np data packets, where np = 24, 12, 6, or 3, and the value of np is determined by 
the numPkts parameter of the most recent HDL_Send_Req or HDL_Rev_Req service 
primitive. Same as an HDL_DATA PDU as defined in C.5.4.4.1. 

a number indicating the ordinal position of a data packet within a tx frame, such that packet 
index = 0 indicates that the data packet occupies the first position in the tx frame. 

the combination of a data packet with the packet index indicating the data packet’s ordinal 
position within a specific tx frame. 


rx frame a sequence of np indexed packets, where 0 < np < 24, which includes an indexed packet 
containing each data packet that was received without errors (as determined by checking its 
CRC) in an incoming tx frame. np is never greater than the value of the numPkts parameter of 
the most recent HDL_Rcv_Req service primitive, but may be less due to packets’ having been 
omitted from the rx frame (by the BW2 receiver) due to their having been received containing 
errors. 
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C.5.4.3 Service primitives. 

Table C-XLIV describes the service primitives exchanged between the HDL protocol entity HDL 
and one or more user processes at HDL’s upper interface. These service primitives are used in 
this specification only as expository devices, and are not required to be present in any compliant 
implementation of the protocol. Note that there is no requirement that implementations of the 
waveforms and protocols defined in this Appendix contain precisely these service primitives; nor 
are the services primitives defined below necessarily all of the service primitives that would be 
required in an implementation of these waveforms and protocols. 


C.5.4.4 PDUs. 
The sub-sections of this section describe the PDUs exchanged between a HDL protocol HDL 
entity and its remote peer entities. 


C.5.4.4.1 HDL DATA. 

An HDL_DATA PDU is a tx frame as defined in table C-XLIII, in which the format and contents 
of each data packet are as shown in table C-XLV. Table C-XLVI specifies the format and 
contents of the Sequence Number field of each data packet. 
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TABLE C-XLIV. HDL service primitives. 


HDL _Send_Req Overview HDL Send Request: generated by the user process when it has a datagram to send on 
an already-established HF link. 


datagram to be delivered, as described in table C-XLIII. 


numPkts the number np of data packets to be transmitted in each 
forward transmission by BW2 (i.e., each tx frame), where 
a 24, 12, 6, or 3. 


Originator User process 


Preconditions | TM has just completed a SoS SEE ne point-to-point HF link establishment with the 
intended ee recipient. 
ey ee 
processing required to receive an expected incoming datagram. 
Parameters numPkts the number np of data packets that will be received in 
each incoming transmission by BW2, where np = 24, 12, 
eT or 3. 


Originator User process 


Preconditions | TM has just completed a rT ete ee point-to-point HF link establishment with the 
aaa datagram Se §£i $$ ——__—— 


ee (eee 
datagram to give to the local user process. 
Parameters datagram datagram just received, as described in table C-XLIII; 
identical to the original datagram parameter-value of the 
HDL_Send Le ee primitive at the remote station. 


HDL has received an HDL_Rev_Req since for Rg ee last outgoing or incoming datagram 
SS 


HDL _Send_Conf Se HR Confirm: Issued ISS TAL eS HDL when HDL has completed successful delivery of a 
datagram to the remote station. 
Parameters | (none) 
[Originator | ADE 
peperrey HDL was requested to deliver the datagram by the user process by means of an 
Jenin [po Soaks service primitive. 


Pe ee ek = | 
HDL. TATE / Req Se HDL Abort Request: used by the user process to terminate a HDL protocol data 
transfer that is currently in progress. The purpose of this service primitive is only to 
cause the HDL entity to cease attempting to send or receive the current datagram; 
coordinating the data transfer termination with the remote station is the responsibility 
on TM. 


Parameters | (none) 
| Originator | Userprocess | 
eaeeeaeaan aa an ec or an Re data transfer is in progress, using the HDL protocol. 


CRITE awe HDL CES GO Indication: Issued TIGL TNC HDL when HDL is unable to complete delivery of 
an outgoing or incoming (= oe 


aoe ae as alt ee eee = ee a 
Either an outgoing or an incoming data transfer is in progress, using the HDL protocol. 
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TABLE C-XLV. Data packet format. 


Payload 1864 (fixed) any Contains a data segment as defined in table C-XLIII, followed by 
however many zero bytes are needed to fill the Payload field to 
length 233 bytes. Whenever the field contains fewer than 233 bytes 
of payload data (from the outgoing datagram), the value of the 
Sequence Number field indicates how many bytes of payload data are 
present. 


Sequence 17 (fixed) As defined by table C-XLVI. 
Number 


The bytes of the Payload field are transmitted in the order of their occurrence in the datagram; the 
bits of each byte are transmitted in order of significance, starting with the most significant bit. 


HDL_DATA PDUs are transmitted using the BW2 burst waveform described by section C.5.1.5. 


TABLE C-XLVI. Sequence number field definition. 
com som 


only packet in datagram Payload field byte count: the number of bytes 
(octets) of datagram data present in the Payload 
field of the packet. 


last packet in datagram 1} 0 | _o__| Payload field byte count (see above) 


first packet in datagram number of packets required to convey the data contents of the 
datagram, minus one: equal to (the least integer greater than or 
equal to (datagram length in bytes / 233)) - 1. 


acket in interior of aaa acket sequence number: the number of packets 
Pp gp q Pp 
datagram in the current datagram, following the current packet. 


Following the last bit of the Payload field-value, the bits of the Sequence Number field are 
transmitted in order of significance within the 17-bit field-value, starting with the most 
significant bit (bit 16). 


C.5.4.4.2 HDL ACK. 

The HDL_ACK PDU is used to transfer selective acknowledgements, in the form of an ack bit- 
mask containing a single bit for each data packet in an HDL_DATA PDU, from the receiving 
station to the sending station ina HDL transfer. Table C-XLVII specifies the format and 
contents of the HDL_ACK PDU. 
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TABLE C-XLVII. HDL ACK PDU format. 


Field name Size Values Description 
(bits) 


000, =HDL | identifies this PDU as an HDL PDU 
0,=ACK __| Identifies this PDU as an HDL_ACK PDU 


Ack Bit-Mask 24 Contains one ack bit for each of the data packets that can be 
received inan HDL_ DATA PDU. Each bit indicates whether the 
corresponding data packet was received without errors; 1 = ACK 


(was received successfully); 0 = NAK (not received successfully). 


Reserved 4 0000, Reserved for future use. 
(fixed) 


16-bit Cyclic Redundancy Check (CRC) computed across the values 
of the Type and Ack Bit-Mask fields, using the generator 


+X +X! 4 KS + Ko 4+ XP 4 X44 X74 X41 
and the procedure described in C.4.1. 


The fields of the HDL_ACK PDU are transmitted in the order of their occurrence in table 
C-XLVII, protocol field first. Bits of the Ack Bit-Mask field are transmitted in the order in 
which the corresponding data packets were transmitted in the HDL_DATA PDU that is being 
acknowledged; for instance, the first ack bit acknowledges the first data packet. 


HDL_ACK PDUs are transmitted using the BW1 burst waveform described by section C.5.1.4. 


C.5.4.4.3 HDL EOM. 

The HDL_EOM PDU is sent from the sending station to the receiving station in a HDL transfer, 
to indicate that the sending station has received acknowledgements from the receiving station of 
every data packet in the datagram being transferred, and hence will send no more HDL_ DATA 
PDUs for the current datagram. The HDL_EOM PDU is sent as many times as possible within 
the time interval defined for a forward transmission (based on the value of numPkts), to 
maximize the probability of its being received without errors. Table C-XLVIII specifies the 
format and contents of the HDL _EOM PDU. 


TABLE C-XLVIII. HDL _EOM PDU. 


Field name size Values Description 
(bits) 


Protocol  |3 | 000, = HDL identifies this PDU as an HDL PDU 


Type Type 1,=EOM Identifies this PDU as an HDL_EOM PDU. 


Check OxASASASA5__| Unused, but should be inspected by the recipient to verify that it 
ASA contains the correct bit-pattern specified here. 


The fields of the HDL_EOM PDU are transmitted in the order of their occurrence in table 
C-XLVIII, protocol field first. The bits of the Check field are transmitted following the single bit 
of the Type field in order of significance, most significant bit first, so that the first four bits 
transmitted from the Check field are 1, 0, 1, 0. 


HDL_EOM PDUs are transmitted using the BW1 burst waveform described by section C.5.1.4. 
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On traffic links established for packet traffic delivered using the HDL protocol, the user process 
can terminate the data link transfer and use the next data link transmission time slot in either 
direction — i.e., the time slot for the HDL_DATA or the HDL_ACK PDU — to instead send one 
or more TM PDUs (described in C.5.3.4) within the data link PDU time-slot. This means that 
while a HDL transfer is in progress, the receiving station must be simultaneously attempting to 
demodulate TM PDUs conveyed by the BW1 waveform as it is attempting to demodulate and 
receive HDL_DATA PDUs conveyed by BW2. The sending station may receive a TM PDU 
conveyed by BW1 in place of an HDL_ACK PDU (also BW1), and must ensure that this PDU is 
received and processed by its TM sublayer. 


C.5.4.5 Protocol behavior. 
This section provides an informal overview of the behavior of the HDL protocol. The following 
sections define this behavior precisely: 


e C.5.4.5.1 identifies and defines the events to which HDL responds; 
e C.5.4.5.2 identifies and defines the actions taken by HDL in response to these events; 
e C.5.4.5.3 describes the data items used and maintained by HDL; 


e C.5.4.5.4 provides a state diagram and a state transition table specifying the behavior of 
HDL in terms of these events, actions, and data items; and 


e C.5.4.5.5 provides additional information on the timing characteristics of HDL 
behavior. 


Data transfer by HDL begins after the TM sublayer has already established the data link 
connection, in so doing negotiating the fact that HDL will be used (as opposed to LDL or some 
other mechanism), the number of data packets to be sent in each HDL_DATA PDU, and the 
precise time synchronization of data link transmissions. 


In an HDL data transfer, the sending station and the receiving station alternate transmissions in 
the manner depicted in figure C-33, the sending station transmitting HDL_DATA PDUs 
containing payload data packets, and the receiving station transmitting HDL_ACK PDUs 
containing acknowledgements of the data packets received without errors in the preceding 
HDL_DATA PDU. If either station fails to receive a PDU at the expected time, it sends its own 
next outgoing PDU at the same time as if the incoming PDU had been received successfully. 
The times at which the burst waveforms conveying HDL_ DATA, HDL_ACK, and HDL_EOM 
PDUs may be emitted are precisely stipulated; see C.5.4.5.5 for details. 
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HDL_DATA HDL_DATA HDL_DATA 


HDL_ACK HDL_ACK HDL_ACK 


FIGURE C-33. HDL data transfer overview. 


The end of a data transfer is reached when the sending station has transmitted HDL_ DATA 
PDUs containing all of the payload data in the delivered datagram, and the receiving station has 
received these data without errors and has acknowledged their successful delivery. When the 
sending station receives an HDL_ACK PDU indicating that the entire contents of the datagram 
have been delivered successfully, it sends an HDL_EOM PDU repeated as many times as 
possible within the duration of an HDL_DATA PDU, starting at the time at which it would have 
otherwise transmitted the next HDL_ DATA PDU, to indicate to the receiving station that the 
data transfer will be terminated. This link termination scenario is depicted in figure C-34. 


Contains final outstanding HDL_EOM sent repeatedly to 
packet of datagram; received confirm receipt of last HDL_ACK. 
without errors. | 


HDL_DATA HDL_DATA HDL_EOM HDL_EOM 


Acknowledges final 
packet of datagram; 
received without errors. 


FIGURE C-34. HDL link termination scenario overview. 


The definition of HDL behavior presented in the following sections includes mechanisms for 
dealing appropriately with the following occurrences: 


e excessive number of consecutive failures to receive an expected HDL_DATA PDU; 
e excessive number of consecutive failures to receive an expected HDL_ACK PDU; 


e immediate termination of an ongoing data link transfer requested by the TM sublayer. 


C.5.4.5.1 Events. 

Table C-XLIX defines the events to which the HDL entity responds. The event names are used 
in the state diagram and the state transition table in C.5.4.5.4, which define the behavior of the 
HDL protocol. Some event names refer to the receipt of PDUs from the HDL entity at a remote 
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station; in these cases, the ‘description’ field of the table entry describes the manner in which the 
arrival of a PDU is accomplished through HDL’s accepting one or more service primitives from 
lower-layer entities at the local station. The prefix ‘R:’ in the name of an event indicates that the 
event is the receipt of a PDU from the remote station. “D:’ indicates that the event is an HDL 
service primitive passed down to HDL from a higher-layer entity; ‘U:’ indicates a lower-layer 
service primitive passed up to HDL from a lower-layer entity. 


TABLE C-XLIX. HDL events. 


R:HDL_ DATA PDU A BW2 Receive primitive containing an HDL_ DATA PDU was accepted. 


R:HDL_ACK PDU A BWI Receive primitive containing an HDL_ACK PDU was accepted, and the 
HDL_ACK PDU was found to be free of errors by checking its CRC. 


R:HDL_EOM PDU A BWI Receive primitive containing a HDL_EOM PDU was accepted, and the 
HDL_EOM PDU was found to be free of errors by comparing the received PDU against 
the known HDL_EOM bit pattern specified in table C-XLVII. 


D:HDL Send Req An HDL Send_Req primitive was accepted from the user process. 
D:HDL_ Abort Req An HDL Abort Reg primitive was accepted from the user process. 


A valid HDL_ACK PDU was not received within the time period in which it was 
expected. 


An HDL_DATA PDU was not received within the time period in which it was expected. 


C.5.4.5.2 Actions. 

Table C-L defines the actions which the HDL entity can perform. The action name is used in the 
state diagrams and/or state transition tables used below to define the behavior of the HDL 
protocol. Some action names refer to sending PDUs to the HDL entity at a remote station; in 
these cases, the ‘description’ field of the table entry describes the manner in which sending of the 
PDU is accomplished by issuing one or more service primitives to lower-layer entities at the 
local station. 


C.5.4.5.3 Data. 

Table C-LI defines the data items used and maintained by HDL, including buffers, counters, 
timers, configuration parameters, and so forth. These data items are referred to by the names 
assigned to them here, in the definitions of HDL events and actions presented in the preceding 
sections. These data items are used in this specification only as expository devices, and are not 
required to be present in any compliant implementation of the protocol. 
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TABLE C-L. HDL actions. 


TxInit Set NumPktsTx to the value of the numPkts parameter of the HDL_Send_Req primitive. 
Insert the outgoing datagram into TxDatagramBuf. Clear TxFrameBuf. Reset 


MissedAckCount to zero. 


S:HDL_ DATA For each of the first NumPktsTx data packet positions in TxFrameBuf, if the data packet 
position is empty, construct a new outgoing data packet (as described by table C-XLV) in this 
position: 

1. Get the next data segment (the next 233 consecutive data bytes to be transmitted) from 
TxDatagramBuf; place these in the Payload field of the data packet. If fewer than 233 
data bytes remain to be transmitted, place these bytes at the beginning of the Payload field; 
fill the remainder of the field with zero bytes. 

2. Construct a sequence number value as specified in table C-XLVI; write this value into the 
packet’s Sequence Number field. 

If TxDatagramBuf is completely emptied of payload data before all packet positions in 

TxFrameBuf have been filled with new packets, fill the remaining packet positions with 

repetitions of packets already residing in other positions of TxFrameBuf. Note: The HDL 

transmitter is at liberty to select packets from the current datagram to repeat as it pleases; the 

HDL receiver must inspect the sequence number of each packet received without errors, and 

use this information to discard duplicate packets. Note: Whenever a packet is retransmitted, 

it is always placed in the same packet position within the Tx frame that it occupied in the 


previous transmission. 

Send an HDL_DATA PDU containing the tx frame in TxFrameBuf, using a BW2_ Send 
primitive. Set the primitive’s reset parameter to TRUE if this is the first tx frame transmitted 
for the current datagram, and to FALSE otherwise. 

Reset the AckTimeout timer. If an AckTimeout has occurred, increment MissedAckCount. 


ProcessAck Check the HDL_ACK PDU’s CRC. Ifthe CRC is valid: 
1. Copy the Ack Bit-Mask field value to RxAck. 
2. For each i, 0 <i <(NumPktsTx - 1), if RxAck[i] is 1, clear the i® position of TxFrameBuf. 
(Each unacknowledged packet is retained in its current position in TxFrameBuf, and will 
be retransmitted in the same position that it occupied in the previous transmission.) 
3. If TxDatagramBuf is not empty, set the condition MoreToSend to TRUE; otherwise set it 


to FALSE. 


S:HDL_EOM Send an HDL_EOM PDU to the remote station using BW1_ Send, as many times as possible 
within the duration of an HDL_ DATA PDU. The number of times the HDL_EOM PDU is 
sent depends on the value of NumPktsTx as follows: 

e if NumPktsTx = 3, the HDL_EOM PDU is transmitted once 

e if NumPktsTx = 6, the HDL_EOM PDU is transmitted once 

e if NumPktsTx = 12, the HDL_EOM PDU is transmitted three times 
e if NumPktsTx = 24, the HDL_EOM PDU is transmitted seven times. 


Disable AckTimeout timer. 


U:HDL Send Conf | Issue an HDL_Send_ Conf primitive to the user process that requested the outgoing data 
transfer. 


RxInit Set NumPktsRx to the value of the numPkts parameter of the HDL_Rcev_Req primitive. 
Clear RxDatagramBuf, and RxFrameBuf. 
Reset MissedTxFrameCount to zero. 
Set CompleteDatagramRcvd to FALSE. 
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TABLE C-L. HDL actions (continued). 


S:HDL_ACK(ack/nak) | Clear TxAck to all zeroes. 
Reset MissedTxFrameCount to zero. 
if CompleteDatagramRcevd is FALSE then 
For each indexed packet received from the BW2 receiver, 

. Insert a data packet containing the Payload and Sequence Number field values from 
the indexed packet into RxFrameBufli], where i = the Index value from the indexed 
packet (the packet’s position in the transmitted HDL_DATA PDU). 

. Set TxAck[i] to 1. 

. Move the Payload field contents of RxFrameBuf[1] to the position in 
RxDatagramBuf indicated by the Sequence Number field-value. 

. Ifall packets for the current datagram have been received without errors, set 
CompleteDatagramRcvd to TRUE. 

else (CompleteDatagramRcvd is TRUE) 
Set the first NumPktsRx bits of TxAck to 1. 

end if 
Send an HDL_ACK PDU containing TxAck, using BW1_ Send. 
Reset the DataTimeout timer. 
Note: An implementation of HDL can, without impairing compliance to this standard, 
provide segments of a partially-received datagram to the user process, in order of their 
occurrence in the original datagram at the sending station, before the entire datagram has 
been received. Doing so would allow a higher-layer protocol to abort an ongoing data 
transfer, then resume it at a later time, without having to retransmit the entire portion of the 
current datagram that was already delivered successfully. 
Note: The HDL transmitter can send duplicate packets either as a result of missing an 
HDL_ACK PDU, or at the end of a datagram, in order to fill the (otherwise unused) packet 
positions of an HDL_DATA PDU. The HDL receiver is required to inspect the sequence 
number of each data packet received without errors, and to use the sequence numbers to 
identify and discard duplicate packets. 

S:HDL_ACK(naks) Reset the DataTimeout timer. 
Clear TxAck to all zeroes. 
Send an HDL_ACK PDU containing TxAck using BW1_ Send. 
If a DataTimeout has occurred, increment MissedTxFrameCount. 


U:HDL _Rcv Ind Issue an HDL _Rcv_ Ind primitive containing the received datagram to the user process. 
AbortReceive Disable DataTimeout timer; reset MissedTxFrameCount to zero. 
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TABLE C-LI. HDL data items. 


Up (TSU) phase. 

inserted into a tx frame for transmission. 
frame (an HDL_ DATA PDU). 

during the Traffic Set-Up (TSU) phase. 


buffer storing the data contents of an incoming datagram which have been received 

thus far, in which the complete incoming datagram is re-assembled in correct 

order. 

without errors (as determined by the CRC check performed by the BW2 receiver). 

ack flag sequence to be transmitted to the remote station. Contains one bit-flag for 

each data packet in a maximum-length tx frame; TxAck[i] = 1 indicates that the i” 
data packet in the most recently received rx frame was received without errors. 
ack flag sequence received in an HDL_ACK PDU from the remote station. 
Contains one bit-flag for each data packet in a maximum-length tx frame; 
RxAck{i] = 1 indicates that the remote station received the i data packet in the 
previously-transmitted rx frame without errors. 


which one was expected. 

time period in which one was expected. 

timer used to time the duration of the interval in which receipt of an HDL_ACK 
PDU is expected; fires when the interval expires. 

timer used to time the duration of the interval in which receipt of aa HDL_ DATA 
PDU is expected; fires when the interval expires. 

HDL configuration parameter specifying the maximum number of consecutive 
missed HDL_ACK PDUs that can occur without causing the HDL transmitter to 
terminate the data link transfer. The value of this parameter is not stipulated by 
this specification, since it is not required for interoperability that this parameter 
have identical values in both the sending and receiving stations. 

HDL configuration parameter specifying the maximum number of consecutive 
missed HDL_ DATA PDUs that can occur without causing the HDL receiver to 
terminate the data link transfer. The value of this parameter is not stipulated by 
this specification, since it is not required for interoperability that this parameter 
have identical values in both the sending and receiving stations. 

Boolean condition variable: is TRUE if and only if an outgoing datagram transfer 
is in progress, and there are one or more data packets in the datagram for which the 
local station has not yet received an acknowledgement of their receipt without 
errors by the remote station. 

Boolean condition variable: is TRUE if and only if an incoming datagram transfer 
has been successfully completed (all contents of the datagram received without 
errors), but an HDL_Rcv_Ind primitive has not yet been issued to the user process. 
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C.5.4.5.4 Behavior definition. 

For the reader’s convenience, two equivalent representations of the behavior of the HDL protocol 
are provided in this section: the state transition table in table C-LII, and the state diagram in 
figure C-35. 


Both table C-LII and figure C-35 specify the behavior of HDL in terms of the events defined in 
C.5.4.5.1 and the actions defined in C.5.4.5.2. The conditions gating certain transitions are 
specified in terms of the data items defined in C.5.4.5.3. 


In the state diagram, each state transition is labeled with an event, an optional condition, and zero 
or more actions. This indicates that the state transition occurs whenever the event occurs and the 
condition obtains (is TRUE), causing the associated actions to be performed. In the diagram, 


e the name of each event is shown in brackets preceded by the letter ‘E’; 
e the description of each condition is shown in brackets preceded by the letter ‘C’; and 


e the names of the actions associated with a transition are shown in brackets preceded by 
the letter ‘A’. 


Where a transition is labeled with two or more events, this indicates that the transition occurs 
whenever any of the events occurs. 


E[other] 


E[D:HDL_Rev_Req] 
A[Rxinit] 


E[R:HDL_EOM] 
A{U:HDL_Rev_Ind] 


E[D:HDL_Send_Req] 
A(TxInit + S:!HDL_DATA] 


E[R:HDL_ACK] ; 
E[R:HDL_ACK] CINOT MoreToSend] eee 
C[MoreToSend] A\ProcessAck + 
A\ProcessAck + S:HDL_EOM + ERHDL: DATA 


| . E[DataTimeout] 
SDL DATA Pp L veniam C[(MissedTxFrameCount == AIS:HDL_ACK(acknak)] 


E[AckTimeout] MAX_MISSED_TX_FRAMES) AND 

C[MissedAckCount == NOT CompleteDatagramRcvd] 
MAX_MISSED_ACKS] AAbortReceive+ 

A[AbortTransmit+ U:HDL_Failure_Ind] 


U:HDL_Failure_Ind] E[DataTimeout] 


E[D:HDL_Abort_Req] C[(MissedTxFrameCount == Receive E[other] 
AlAbortTransmit] MAX_MISSED_TX_FRAMES) AND 
CompleteDatagramRcvd] 
A{AbortReceive+ 
U:HDL_Rev_Ind] 


E[AckTimeout] E[DataTimeout] 
C[MissedAckCount < C[MissedTxFrameCount < 
MAX_MISSED_ACKS] MAX_MISSED_TX_FRAMES] 


A[S:HDL_DATA] A[S:HDL_ACK(naks)] 


FIGURE C-35. HDL state diagram. 
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TABLE C-LII. HDL state transition table. 


Idle D:HDL_Send_Req | TInt + Ss HDL_DATA 


voter Pte «i 


R:HDL_ACK MoreToSend ProcessAck + S:HDL_DATA 


R:HDL_ACK NOT MoreToSend ProcessAck + S:HDL_EOM | Idle 
+ U:HDL_Send_Conf 

AckTimeout MissedAckCount < S:HDL_DATA Send 

MAX MISSED ACKS 
AckTimeout MissedAckCount == AbortTransmit + Idle 

MAX MISSED ACKS U:HDL_Failure_Ind 
DDL Abt Ree [| *d Aboranwmit SSS 
rer Pid none SS—*d Se | 


Receive R:HDL_DATA © |S HDL_ACK (ack/nak) 
RHDLEOM |_| USHIDL_Rev_Ind 


DataTimeout MissedTxFrameCount < S:HDL_ACK(naks) Receive 
MAX MISSED TX FRA 
MES 


DataTimeout (MissedTxFrameCount == | AbortReceive + 
MAX MISSED TX FRA | U:HDL Failure Ind 
MES) 
AND 
NOT 
CompleteDatagramRevd 


DataTimeout (MissedTxFrameCount == | AbortReceive + 
MAX MISSED _TX_FRA | U:HDL Rev Ind 
MES) AND 

CompleteDatagramRevd 


oer |i none «id Reeve | 


C.5.4.5.5 Timing characteristics. 
See C.5.3.5.5, which includes an analysis of the timing of the HDL protocol in conjunction with 
TM protocol timing. 


C.5.5 LDL protocol . 


C.5.5.1 Overview. 

The LDL protocol is used to provide reliable acknowledged point-to-point delivery of datagrams 
from a transmitting station to a receiving station across an already-established HF link. The 
datagram passed to the LDL protocol entity for delivery is a finite-length ordered sequence of 8- 
bit data bytes (octets). The LDL protocol provides improved performance for all datagram 
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lengths under fair to very poor HF channel conditions, and under all channel conditions for short 
datagram lengths. 


C.5.5.2 Data object types. 
The terms defined in table C-LIII are used to refer to specific types of data objects in defining the 
LDL protocol. 


TABLE C-LIII. LDL data object types. 
Data object type 
datagram an arbitrary sequence of 8-bit data bytes (octets) of length d/, where 1 < d/l < 16,777,216 (equal 
to (512 * 32,768): i.e., 512 payload data bytes per data packet times a maximum of 32,768 data 


packets per datagram). 


where | <s/< 512. 
0, where p/ is the packet length established for the current LDL transfer (64, 128, 256, or 512). 


sequence number | a 17-bit data object having the format defined in table C-LVI, which indicates the position 
occupied by a data segment within a datagram, and, when the data segment includes the last 


data byte of the datagram, the number of bytes of payload data from the datagram in the data 
segment. 


control field an 8-bit data object reserved for future use. 


data packet the combination of a filled segment with a corresponding sequence number and control field. 
If the data segment contained in the filled segment is of length less than p/ bytes (because it 
includes the last data byte of the datagram), the value of the sequence number indicates how 


many of the p/ bytes in the extended data segment contain payload data from the datagram — 
1.e., the value of s/ for the data segment contained in the filled segment. 


a single data packet. Same as an LDL_DATA PDU as defined in table C-LV. 


rx frame a single data packet that was received without errors, as determined by the CRC check 
performed by the BW3 receiver. 


C.5.5.3 Service primitives. 

Table C-LIV describes the service primitives exchanged between the LDL protocol entity and 
one or more user processes at LDL’s upper interface. Note that there is no requirement that 
implementations of the waveforms and protocols defined in this Appendix contain precisely 
these service primitives; nor are the services primitives defined below necessarily all of the 
service primitives that would be required in an implementation of these waveforms and 
protocols. 
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TABLE C-LIV. LDL service primitives. 


LDL_Send_ Req Overview LDL Send Request: generated by the user process when it has a datagram to 
send on an already-established HF link using the LDL protocol. 
Parameters 
pktLength the number p/ of payload data bytes and fill bytes to be 
transmitted in each data packet transmitted using BW3, 
where p/ = 64, 128, 256, or 512. The value of 
pktLength should correspond to the TrafficT ype field- 
value of the TM REQUEST PDU sent in establishing 
the packet traffic link: e.g., pktLength should be 64 if 
and only if the TrafficType field of the TM REQUEST 
PDU had the value LDL_64. (See C.5.3.4.1.) 
ace ae ee a eee 


eae TM has just completed a successful point-to-point HF link establishment with 
— intended ee recipient. 


perform the processing ened to receive an expected incoming datagram. 
Parameters pktLength the number p/ of payload data bytes or fill bytes 

expected to be present in each incoming data packet 
received by the BW3 receiver, where p/ = 64, 128, 256, 
or 512. The value of pktLength should correspond to 
the TrafficType field-value of the TM REQUEST PDU 
received when the packet traffic link was established: 
e.g., pktLength should be 512 if and only if the 
TrafficType field of the TM REQUEST PDU had the 
value ee (See C.5.3.4.1.) 


Originator User process 


cers TM has just del TERE SEL DAT Satie a successful point-to-point HF link establishment with 
ie expected datagram sender. 


LS Penn ee a et 
received datagram to give to the local user process. 
Parameters datagram datagram just received, as described in table C-LIII; 
identical to the datagram parameter-value of the original 
LDL _Send_ Req primitive at the remote station. 
eS ee a eee 


Precondition | LDL has accepted an LDL_Rev_Req service primitive from a higher-layer 
S emma since the last ee or incoming datagram transfer. 


Bras ee ihe al 
LDL Send Conf | Overview LDL Send Confirm: Issued Gand ty LOC ARDC age acca LDL when LDL has completed successful 
ee 
ears) 
[LDL 


poet LDL was requested to = dal ISRO the datagram by the user process by means of 
an LDL _ Send aaa service a 
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TABLE C-LIV. LDL service primitives (continued). 


LDL Abort Req | Overview LDL Abort Request: used by the user process to terminate an LDL protocol 
data transfer that is currently in progress. The purpose of this service 
primitive is only to cause the LDL entity to cease attempting to send or 
receive the current datagram; coordinating the data transfer termination with 
on remote station is the ey of TM. 


Parameters 
Originator cle process 


Preconditions | Either an outgoing or an incoming oa cag JE Ean GRIST transfer is in progress, using the LDL 
_ SSS ee 
LDL_ Failure Ind Simi LDL F -i-tatus inal ieaed by COCs Banke Beare Indication: Issued by LDL when LDL is unable to complete 
Fe eel of an ye or incoming datagram. 


Parameters _| ‘(none) sid 


Either an outgoing or an incoming EST ITO transfer is in progress, using the LDL 
ss at 


C.5.5.4 PDUs. 
The sub-sections of this section describe the PDUs exchanged between an LDL protocol entity 
and its remote peer entities. 


The LDL_ACK and LDL_EOM PDUs are conveyed using BW4 and thus require no special 
distinction from TM PDUs which are conveyed using BW1. The LDL_ ACK and LDL_ EOM 
PDUs are distinguished from one another by context: any PDU sent using BW4 in the forward 
direction is an LDL_EOM PDU, while any PDU sent using BW4 in the reverse direction is an 
LDL_ACK PDU. 


C.5.5.4.1 LDL DATA. 

An LDL_DATA PDU is a tx frame as defined in table C-LIII, in which the format and contents 
of each data packet are as shown in table C-LV. Table C-LVI specifies the format and contents 
of the Sequence Number field of each data packet. 


TABLE C-LV. Data packet format. 


Payload 512, 1024, Contains a filled segment as defined in table C-LIII: i.e., a data 
2048, or 4096 segment followed by however many zero bytes are needed to fill the 
(fixed for Payload field to the length given by PacketLength as defined in table 
each C-LXI. Whenever the field contains fewer than PacketLength bytes 


datagram of payload data from the datagram being delivered (the remainder 
transfer) being fill bytes with value 0), the value of the Sequence Number field 
indicates how many bytes of payload data are present. 


Sequence 17 (fixed) As defined by table C-LXVI. 
Number 


8 (fixed) Reserved (set to zero); must be ignored by the receiving station. 


417 


MIL-STD-188-141B 
APPENDIX C 


The fields of the LDL_DATA PDU are transmitted in order of their occurrence in table C-LV, 
Payload field first. The bytes of the Payload field are transmitted in the order of their occurrence 
in the datagram; the bits of each byte are transmitted in order of significance, starting with the 
most significant bit. Following the last bit of the Payload field-value, the bits of the Sequence 
Number field are transmitted in order of significance within the 17-bit field-value, starting with 
the most significant bit (bit 16). Finally, the bits of the Control field are transmitted in order of 
significance, most significant bit first. 


LDL_DATA PDUs are transmitted using the BW3 burst waveform described by section C.5.1.6. 


TABLE C-LVI. Sequence number field definition. 


Case Bit _ Bit 7 Bits Bits 9 - 0 
eom Gem 14-10 


only packet in datagram Payload field byte count: the number of bytes 
(octets) of datagram data present in the Payload 
field of the packet. 


last packet in datagram — 1 | 0 | 0 __| Payload field byte count (see above) 


first packet in datagram 1 number of packets required to convey the data contents of the 
datagram, minus one: equal to (the least integer greater than or 
equal to (datagram length in bytes / PacketLength (as defined in 

aie table C-LXI) ) - 1. 
packet in interior of down-counting packet sequence number: the number of packets 
eee en oe. in the current datagram, following the current packet. 

C.5.5.4.2 LDL ACK. 

The LDL_ACK PDU is used to transfer acknowledgement, in the form of an ack bit for the data 

packet in the immediately preceding LDL_DATA PDU, from the receiving station to the sending 


station in an LDL transfer. Table C-LVII specifies the format and contents of the LDL_ACK 
PDU. 


TABLE C-LVII. LDL ACK PDU format. 


Field name Size Values Description 
(bits) 


Ack Bit 1 any Contains one ack bit for the data packet received in an LDL_DATA 
PDU. The bit indicates whether the corresponding data packet was 
received without errors; | = ACK (was received successfully); 0 = 


NAK (not received successfully). 
CompleteDatagra Contains one bit to indicate that the data packet received in the 
mRevd immediately previous LDL_DATA PDU is understood by the 
receiving station to be the last data packet of the datagram; | = 
complete datagram received; 0 = complete datagram not received. 


Of the two bits of the LDL_ACK PDU, the Ack Bit is transmitted first. 


LDL_ACK PDUs are transmitted using the BW4 burst waveform described by section C.5.1.7. 
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C.5.5.4.3 LDL _EOM. 

The LDL_EOM PDU is sent from the sending station to the receiving station in an LDL transfer, 
to indicate that the sending station has received acknowledgements from the receiving station of 
every data packet in the datagram being transferred, and hence will send no more LDL DATA 
PDUs for the current datagram. The LDL_EOM PDU is sent as many times as possible within 
the time interval defined for a forward transmission, to maximize the probability of its being 
received without errors. Table C-LVIII specifies the format and contents of the LDL_EOM PDU. 


TABLE C-LVIII. LDL _EOM PDU format. 


Size (bits) 
I (fixed) 
I (fixed) 


Of the two bits of the LDL_EOM PDU, the Unused bit is transmitted first. 
LDL_EOM PDUs are transmitted using the BW4 burst waveform described by section C.5.1.7. 


On traffic links established for packet traffic delivered using the LDL protocol, the user process 
can terminate the data link transfer and use the next data link transmission time slot in either 
direction — i.e., the time slot for the LDL_DATA or the LDL_ACK PDU — to instead send one 
or more TM PDUs (described in C.5.3.4) within the data link PDU time-slot. This means that 
while an LDL transfer is in progress, the receiving station must be simultaneously attempting to 
demodulate TM PDUs conveyed by the BW1 waveform as it is attempting to demodulate and 
receive LDL_DATA PDUs conveyed by BW3. The sending station must likewise 
simultaneously attempt to demodulate and recetve TM PDUs conveyed by the BW1 waveform as 
it is attempting to demodulate and receive LDL_ACK PDUs conveyed by BW4. Since the 
duration of the BW1 burst is longer than that of the BW4 burst, if the sending station detects a 
BWI preamble during the LDL_ACK time-slot, it must skip the transmission of the next 
LDL_DATA PDU in order to be able to receive the remainder of the BW1 burst. If the received 
BW1 burst is a TM PDU, then the sending station must ensure that this PDU is received and 
processed by its TM sublayer. 


C.5.5.5 Protocol behavior. 
This section provides an informal overview of the behavior of the LDL protocol. The following 
paragraphs define this behavior precisely: 


e C.5.5.5.1 identifies and defines the events to which LDL responds; 
e C.5.5.5.2 identifies and defines the actions taken by LDL in response to these events; 
e C.5.5.5.3 describes the data items used and maintained by LDL; 


e C.5.5.5.4 provides a state diagram and an equivalent state transition table specifying the 
behavior of LDL in terms of these events, actions, and data items; and 


e C.5.5.5.5 provides additional information on the timing characteristics of LDL behavior. 
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Data transfer by LDL begins after the TM sublayer has already established the data link 
connection, in so doing negotiating the fact that LDL will be used (as opposed to HDL or some 
other mechanism), and the precise time synchronization of data link transmissions. 


In an LDL data transfer, the sending station and the receiving station alternate transmissions in 
the manner depicted in figure C-36, the sending station transmitting LDL_DATA PDUs 
containing payload data packets, and the receiving station transmitting LDL_ACK PDUs 
containing acknowledgement of whether or not the data packet in the preceding LDL_ DATA 
PDU was received without error. If either station fails to receive a PDU at the expected time, it 
sends its own next outgoing PDU at the same time as if the incoming PDU had been received 
successfully. The times at which the burst waveforms conveying LDL_DATA, LDL_ACK, and 
LDL_EOM PDUs may be emitted are precisely stipulated. See C.5.5.5.5 for details. 


LDL_DATA LDL_DATA LDL_DATA 


LDL_ACK LDL_ACK LDL_ACK 


FIGURE C-36. LDL data transfer overview. 


The end of a data transfer is reached when the sending station has transmitted LDL_DATA 
PDUs containing all of the payload data in the delivered datagram, and the receiving station has 
received these data without errors and has acknowledged their successful delivery. When the 
sending station receives an LDL_ACK PDU indicating that the entire contents of the datagram 
have been delivered successfully, it sends an LDL_EOM PDU repeated as many times as 
possible within the duration of an LDL_DATA PDU, starting at the time at which it would have 
otherwise transmitted the next LDL_DATA PDU, to indicate to the receiving station that the data 
transfer will be terminated. This link termination scenario is depicted in figure C-37. See 
C.5.5.5.5 for timing details. 


Contains final outstanding LDL_EOM sent repeatedly to 

packet of datagram; received confirm receipt of last LDL_ACK. 

without errors. | 
[EDL_paTA DATA LDL_DATA | DATA LDL_EOM LDL_EOM 


[LDL_ack | ACK LDL_ACK | _ACK 


pian final 
packet of datagram; 
pian without errors. 


FIGURE C-37. LDL link termination scenario overview. 
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The definition of LDL behavior presented in the following sections includes mechanisms for 
dealing appropriately with the following occurrences: 


e excessive number of consecutive failures to receive an expected LDL_ DATA PDU; 
e excessive number of consecutive failures to receive an expected LDL_ACK PDU; 


e immediate termination of an ongoing data link transfer requested by the TM sublayer. 


C.5.5.5.1 Events. 

Table C-LIX defines the events to which the LDL entity responds. The event names are used in 
the state diagram and the state transition table in C.5.5.5.4, which define the behavior of the LDL 
protocol. Some event names refer to the receipt of PDUs from the LDL entity at a remote 
station; in these cases, the ‘description’ field of the table entry describes the manner in which the 
arrival of a PDU is accomplished through LDL’s accepting one or more service primitives from 
lower-layer entities at the local station. The prefix ‘R:’ in the name of an event indicates that the 
event is the receipt of a PDU from the remote station. ‘D:’ indicates that the event is an LDL 
service primitive passed down to LDL from a higher-layer entity; ‘U:’ indicates a lower-layer 
service primitive passed up to LDL from a lower-layer entity. 


C.5.5.5.2 Actions. 

Table C-LX defines the actions which the LDL entity can perform. The action name is used in 
the state diagrams and/or state transition tables used below to define the behavior of the LDL 
protocol. Some action names refer to sending PDUs to the LDL entity at a remote station; in 
these cases, the ‘description’ field of the table entry describes the manner in which sending of the 
PDU is accomplished by issuing one or more service primitives to lower-layer entities at the 
local station. 


TABLE C-LIX. LDL events. 


R:LDL_DATA PDU A BW3 Receive primitive containing an LDL_DATA PDU was accepted. 
R:LDL_ACK PDU A BW4 Receive primitive containing an LDL_ACK PDU was accepted. 


R:LDL_EOM PDU A BW4 Receive primitive containing an LDL_EOM PDU was accepted, and the 
LDL_EOM PDU was found to be free of errors by comparing the received PDU against 
the known LDL_EOM bit pattern specified in C.5.5.4.3. 


D:LDL_ Send_Req An LDL Send_Req primitive was accepted from the user process. 


D LDL Abort Req An LDL Abort Req primitive was accepted from the user process 


U:BW1 Pre Detect A BWI Pre Detect primitive was received, indicating that the BW1 Receiver has 
detected the BW1 acquisition preamble, with the likely implications that the remote 
station has sent a TM PDU in the current LDL_ACK time slot. 


A valid LDL_ACK PDU was not received within the time period in which it was 
expected 


An LDL_DATA PDU was not received within the time period in which it was expected. 
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TABLE C-LX. LDL actions, 


TxInit Insert the outgoing datagram into TxDatagramBuf. 
Clear TxFrameBuf. 
Reset MissedAckCount to zero. 
Set PacketLength to the value of the pktLength parameter of the LDL_Send_Req service 
primitive just accepted by LDL. 
S:LDL_DATA If the TxFrameBuf is clear, construct a new outgoing data packet (as described by table C- 
LV) in the following manner: 
1. Get the next data segment (the next PacketLength consecutive data bytes to be transmitted) 
from TxDatagramBuf; place these in the Payload field of the data packet. If fewer than 
PacketLength data bytes remain to be transmitted, place these bytes at the beginning of the 
Payload field; fill the remainder of the field with zero-valued bytes so that the Payload 
field contains a filled segment. 
2. Construct a sequence number value as specified in table C-LVI; write this value into the 
packet’s Sequence Number field. 
3. Construct a control field with all 8 bits set to zero. 
4. Place the data packet generated in steps 1-3 into the TxFrameBuf. 
Send an LDL_DATA PDU containing the tx frame in TxFrameBuf, using a BW3_ Send 
primitive. Set the primitive’s reset parameter to TRUE if this is the first transmission of a tx 
frame for the current datagram, and to FALSE otherwise. 
If an AckTimeout has occurred, increment MissedAckCount. 
Reset AckTimeout timer. 
ProcessAck Copy the Ack Bit-Mask field value to RxAck. 
If RxAck is 1, clear the TxFrameBuf. 


If TxDatagramBuf is not empty, set the condition MoreToSend to TRUE; otherwise set it to 
FALSE. 


S:LDL_EOM Send an LDL_EOM PDU to the remote station using BW4 _ Send, as many times as possible 
within the duration of an LDL_DATA PDU. The number of times the LDL_EOM PDU is sent 
depends on the value of PacketLength as follows: 

e if PacketLength = 64, the LDL_EOM PDU is transmitted once 

e if PacketLength = 128, the LDL_EOM PDU is transmitted three times 

e if PacketLength = 256, the LDL_EOM PDU is transmitted five times 

e if PacketLength = 512, the LDL_EOM PDU is transmitted eleven times. 
Disable AckTimeout timer. 

Skip LDL_DATA Do not send an LDL_DATA PDU in the next LDL_DATA time slot, so that an incoming 

slot BWI burst can be received. However, continue the LDL slot timing, and be prepared to send 
an LDL_DATA PDU in the slot after the next one. 


U:LDL_Send_Conf | Issue an LDL_Send_Conf primitive to the user process that requested the outgoing data 
transfer. 


RxInit Clear RxDatagramBuf, and RxFrameBuf. 
Reset MissedTxFrameCount to zero. 
Reset CompleteDatagramRcvd. 
Reset DataTimeout timer. 
Set PacketLength to the value of the pktLength parameter of the LDL_Rcv_Req service 
primitive just accepted by LDL. 
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TABLE C-LX. LDL actions (continued). 


S:LDL_ACK(ack) | Reset MissedTxFrameCount to zero. 
Insert the received data packet containing the Payload and Sequence Number field into 
RxFrameBuf. 
Set TxAck to 1. 
Move the Payload field contents of RxFrameBuf to the position in RxDatagramBuf indicated 
by the Sequence Number field-value. In doing this, move only payload data bytes into 
RxDatagramBuf; discard any fill bytes. Use the Sequence Number field-value to determine 
which bytes contain payload data and which are fill bytes. 
If the entire datagram has been received, set CompleteDatagramRcvd. 
Reset DataTimeout timer. 
Send an LDL_ACK PDU containing the TxAck and CompleteDatagramRcvd values, using 
BW4 Send. 
Note: An implementation of LDL can, without impairing compliance to this standard, provide 
segments of a partially-received datagram to the user process, in order of their occurrence in 
the original datagram at the sending station, before the entire datagram has been received. 
Doing so would allow a higher-layer protocol to abort an ongoing data transfer, then resume it 
at a later time, without having to retransmit the entire portion of the current datagram that was 
already delivered successfully. 
Note: The LDL transmitter can send duplicate packets either as a result of missing an 
LDL_ACK PDU, or at the end of a datagram, in order to fill the (otherwise unused) packet 
positions of an LDL_DATA PDU. The LDL receiver is required to inspect the sequence 
number of each data packet received without errors, and to use the sequence numbers to 
identify and discard duplicate packets. 


S:LDL_ACK(nak) | Clear TxAck. 
Send an LDL_ACK PDU containing the TxAck and CompleteDatagramRcvd values, using 
BW4 Send. 
If a DataTimeout has occurred, increment MissedTxFrameCount. 
Reset the DataTimeout timer. 


U:LDL_ Rev Ind Send an LDL _Rcv Ind service primitive to the user process. 


AbortReceive Disable DataTimeout timer; reset MissedTxFrameCount to zero. 
ee eee 


C.5.5.5.3 Data. 

Table C-LXI defines the data items used and maintained by LDL, including buffers, counters, 
timers, configuration parameters, and so forth. These data items are referred to by the names 
assigned to them here, in the definitions of LDL events and actions presented in the preceding 
sections. 


C.5.5.5.4 Behavior definition. 

For the reader’s convenience, two equivalent representations of the behavior of the LDL protocol 
are provided in this section: the state transition table in table C-LXII, and the state diagram in 
figure C-38. 


Both table C-LXII and figure C-38 specify the behavior of LDL in terms of the events defined in 
C.5.5.5.1 and the actions defined in C.5.5.5.2. The conditions gating certain transitions are 
specified in terms of the data items defined in C.5.5.5.3. 
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TABLE C-LXI. LDL data items. 


TxDatagramBuf buffer storing the data contents of an outgoing datagram which have not yet been 
inserted into a tx frame for transmission. 


TxFrameBuf buffer storing the outgoing tx frame (an LDL_ DATA PDU). 


RxDatagramBuf buffer storing the data contents of an incoming datagram which have been 
received thus far, in which the complete incoming datagram is re-assembled in 
correct order. 

buffer storing the most recent rx frame that was received without errors (as 
determined by the CRC check performed by the BW3 receiver). 

ack flag to be transmitted to the remote station. TxAck = | indicates that the data 
packet in the most recently received rx frame was received without errors. 

RxAck ack flag received in an LDL_ACK PDU from the remote station. RxAck = 1 
indicates that the remote station received the data packet in the previously- 
transmitted frame without errors. 
which one was expected. 
time period in which one was expected. 

timer used to time the duration of the interval in which receipt of an LDL_ACK 
PDU is expected; fires when the interval expires. 

timer used to time the duration of the interval in which receipt of an LDL_ DATA 
PDU is expected; fires when the interval expires. 

MAX MISSED ACKS LDL configuration parameter specifying the maximum number of consecutive 
missed LDL_ACK PDUs that can occur without causing the LDL transmitter to 
terminate the data link transfer. The value of this parameter is not stipulated by 
this specification, since it is not required for interoperability that this parameter 
have identical values in both the sending and receiving stations. 

MAX MISSED TX FRAMES | LDL configuration parameter specifying the maximum number of consecutive 
missed LDL_DATA PDUs that can occur without causing the LDL receiver to 
terminate the data link transfer. The value of this parameter is not stipulated by 


this specification, since it is not required for interoperability that this parameter 
have identical values in both the sending and receiving stations. 


CompleteDatagramRcvd flag maintained by the receiving station indicating whether or not the entire 
datagram has been successfully received. 


MoreToSend Boolean condition variable: is TRUE if and only if an outgoing datagram transfer 
is in progress, and there are one or more data packets in the datagram for which 
the local station has not yet received an acknowledgement of their receipt without 
errors by the remote station. 


PacketLength number of payload data bytes and fill bytes (if any) carried within each LDL 
forward transmission in the current datagram transfer; possible values are 64, 
128, 256, and 512. The value of PacketLength is determined by the pktLength 
parameter of the LDL_Send_ Req or LDL_Rcv_ Req service primitive that was 
accepted by LDL just prior to the start of the datagram transfer. 


In the state diagram, each state transition is labeled with an event, an optional condition, and zero 
or more actions. This indicates that the state transition occurs whenever the event occurs and the 
condition obtains (is TRUE), causing the associated actions to be performed. On figure C-38, 

e the name of each event is shown in brackets preceded by the letter ‘E’; 
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e the description of each condition is shown in brackets preceded by the letter ‘C’; and 
e the names of the actions associated with a transition are shown in brackets preceded by 
the letter ‘A’. 


E[R:LDL_ACK] 

C[MoreToSend] 

A[ProcessAck + 
S:LDL_DATA] 


E[other] 


E[AckTimeout] 

C[MissedAckCount < 
MAX_MISSED_ACKS] 

A[S:LDL_DATA] 


E[D:LDL_Send_Req] 
A(TxInit + S:LDL_DATA] 


E[R:LDL_ACK] 

C[NOT MoreToSend] 

A[ProcessAck + 
S:LDL_EOM + 
U:LDL_Send_Conf] 


E[AckTimeout] 

C[MissedAckCount == 
MAX_MISSED_ACKS] 

A{AbortTransmit+ 
U:LDL_Failure_Ind] 


E[D:LDL_Abort_Req] 
A{AbortTransmit] 


E[U:BW1_Pre_Detect] 
A[Skip LDL_DATA slot] 


E[other] 


E[D:LDL_Rev_Req] 
A{Rxinit] 


E[R:LDL_EOM] 
A[U:LDL_Rev_Ind] 


E[D:LDL_Abort_Req] 
AAbortReceive] 


E[R:LDL_DATA] 


E[DataTimeout! 
A[S:LDL_ACK(ack)] 


C[(MissedTxFrameCount == 
MAX_MISSED_TX_FRAMES) AND 
NOT CompleteDatagramRcvd] 

A{AbortReceivet+ 

U:LDL_Failure_Ind] 


E[DataTimeout] 
C[(MissedTxFrameCount == 
MAX_MISSED_TX_FRAMES) AND 
CompleteDatagramRcvd] 
AAbortReceivet+ 
U:LDL_Rev_Ind] 


Receive 


E[DataTimeout] 

C[MissedTxFrameCount < 
MAX_MISSED_TX_FRAMES] 

A[S:LDL_ACK(nak)] 


FIGURE C-38. LDL state diagram. 


Where a transition is labeled with two or more events, this indicates that the transition occurs 
whenever any of the events occurs. 
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TABLE C-LXII. LDL state transition table. 


MoreToSend 


NOT MoreToSend 


State 
R:LDL_ACK 


R:LDL_ACK 
AckTimeout MissedAckCount < 


Send 
D:LDL_Abort_ Req 


MAX MISSED_ACKS 


other 


MissedAckCount == 
Reeeve | RLDLDATA [SS 
MissedTxFrameCount < 


MAX MISSED _TX_FRA 
MES 


(Missed TxFrameCount == 
MAX MISSED TX FRA 
MES) 

AND 

NOT 
CompleteDatagramRevd 
(MissedTxFrameCount == 
MAX MISSED TX FRA 
MES) 

AND 
CompleteDatagramRevd 


R:LDL_EOM 


DataTimeout 


DataTimeout 


DataTimeout 


D:LDL_Abort_ Req 
ee 


C.5.5.5.5 Timing characteristics. 


TxInit + S:LDL_ DATA 


none Idle 


Idle 


+ S:LDL_ DATA 


ProcessAck + S:LDL_EOM 
+ U:LDL_Send_Conf 


Skip LDL_ Data slot 


S:LDL_DATA Send 


U:LDL_Failure_Ind 


S:LDL_ACK(nak) 


Idle 


ProcessAck 4 


AbortReceive + 
U:LDL Failure Ind 


AbortReceive + 
U:LDL_Rcev_Ind 


See C.5.3.5.5, which includes an analysis of the timing of the LDL protocol in conjunction with 


TM protocol timing. 
C.5.6 CLC. 


C.5.6.1 Overview. 


The CLC monitors and coordinates traffic on an established circuit link. It provides a simple 


listen-before-transmit access control mechanism: 
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e Transmission of new outgoing traffic is inhibited whenever the CLC detects that the 
circuit link is busy, due to either traffic being received from another station, or traffic 
currently being transmitted by the local station. 


e At the end of each outgoing or incoming traffic transmission, the CLC continues to 
inhibit transmission of new outgoing traffic for the duration of a backoff interval. 


In addition, the CLC provides a traffic timeout indication when an interval of a specified duration 
elapses in which no outgoing or incoming traffic is detected on the circuit link, allowing the 
traffic link to be terminated when no longer required. 


The CLC is employed only on circuit links. 


C.5.6.2 Service primitives. 
Table C-LXIII describes the service primitives exchanged between the CLC and one or more user 


processes at the CLC’s upper interface. Note that there is no requirement that implementations 
of the waveforms and protocols defined in this Appendix contain precisely these service 
primitives; nor are the services primitives defined below necessarily all of the service primitives 
that would be required in an implementation of these waveforms and protocols. 


TABLE C-LXIII. CLC service primitives. 


CLC_Active Req | Overview CLC Active Request: issued to CLC by the user process to request that CLC 
begin monitoring and arbitration of access to the currently-established circuit 
link, using the indicated priority level in its backoff mechanism. CLC sets its 
data item TrafficPriority to the value of the prio parameter. 

Parameters prio priority level of waiting outgoing traffic (if any); value is 

one of 

e P2P: a point-to-point circuit link is being established, 
which is treated as a special case by CLC: the backoff 
delay depends on which station has just transmitted, 
rather than on traffic priority 
TM: TM is waiting to send a TM-PDU 
HIGHEST: highest priority level for user traffic 
HIGH 
ROUTINE 
LOW: lowest priority level for user traffic; also serves 
as default value when no Fae cc nectar traffic is pending. 


Originator user process 


CLC is Idle; a circuit dite a ie was just established by the Traffic Manager. 
CLC_Idle Req ae CLC Idle Request: issued to CLC by the user process to request that CLC 
ee to monitor ; arbitrate access to the current circuit link. 
| Parameters | ‘none —ss 


Originator user process 


CLC is presently active: 1.e., not SS En eee residing in its Idle state. 
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TABLE C-LXIII. CLC service primitives (continued). 


CLC_Set Priority | Overview issued to CLC by the user process to request that CLC use the indicated 
outgoing traffic priority level in its backoff mechanism. CLC sets its data 
item TrafficPriority to the value of the prio parameter. 

Parameters prio priority level of waiting outgoing traffic (if any); value is 

one of 

e P2P: a point-to-point circuit link is being established, 
which is treated as a special case by CLC: the backoff 
delay depends on which station has just transmitted, 
rather than on traffic priority 
TM: TM is waiting to send a TM-PDU 
HIGHEST: highest priority level for user traffic 
HIGH 
ROUTINE 
LOW: lowest priority level for user traffic; also serves 
as default value when no Cn pcan anc eS a traffic is pending. 


Originator user process 


none: can be ao inte by CLC in any state. 


CLC_ ak tie ka — Ind Se CLC Idle Indication: issued to the user process AE WICnSign a WIE CIR ESTE CLC, to indicate that CLC 
is ceasing to monitor and arbitrate access to the current circuit link due to 
occurrence of a traffic timeout (no link traffic detected over a time interval of 
a specific duration). 


Parameters | none | 
| Originator [CLC | 


een CLC is presently active: 1.e., not presently residing in its Idle state. 
peared 


a ee! 
CLC_Busy _ ate SmI CLC Busy Indication: issued to the user process by CLC, to indicate that CLC 
considers the circuit link to be busy — i.e., unavailable for new traffic 
because of a traffic exchange currently in progress, or because a backoff 
period following a traffic exchange has not yet expired. 
[Parameters [none | 
|Originator [CLC PT 


Precondition | CLC is either 
S e newly-activated: i.e., the most recent service primitive passed between 
CLC and the user process was a CLC_Active_Req primitive; or 
e indicating that the traffic link is available: i.e., the most recent service 
primitive passed between CLC and the user process was a CLC_Avail_Ind 
primitive. 
CLC_Avail_Ind eee | CLC Available Indication: issued to the user process by CLC, to indicate that 
Peet: Ia considers the circuit link to be available for new traffic. 


Precondition | CLC is indicating that the traffic link is busy: 1.e., the most recent service 
S primitive passed between CLC and the user process was a CLC_Busy_Ind 
primitive. 
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C.5.6.3 PDUs. 
The CLC does not exchange PDUs with a remote peer entity. 


C.5.6.4 Protocol behavior. 
The following paragraphs define the behavior of the CLC: 


e C.5.6.4.1 identifies and defines the events to which the CLC responds; 


e C.5.6.4.2 identifies and defines the actions taken by the CLC in response to these 
events; 


e C.5.6.4.3 describes the data items used and maintained by the CLC; and 


e C.5.6.4.4 provides a state diagram specifying the behavior of the CLC in terms of these 
events, actions, and data. 


C.5.6.4.1 Events. 
Table C-LXIV defines the events to which the CLC responds. The event names are used in the 
state diagram in C.5.6.4.4, which defines the behavior of the CLC. 


C.5.6.4.2 Actions. 
Table C-LXV defines the actions which the CLC can perform. The action name is used in the 
state diagram used below to define the behavior of the CLC. 
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TABLE C-LXIV. CLC events. 


event name description 


CLC_Active_Req primitive issued by user process, with the indicated value for its prio 
Req (prio) parameter. 
D:CLC_Set_Prio | CLC Set Priority primitive issued by user process, with the indicated value for its prio 
parameter. CLC sets its data item TrafficPriority to the value of the prio parameter. 

current circuit link. 
AudioRTS signal indicating presence of an outgoing audio signal to be transmitted on the current circuit 
oe ol link, such as a handset keyline assertion. 


AudioEOTx signal indicating that transmission of an outgoing audio signal has ended due to, for instance, de- 
assertion of the handset keyline. 


ModemDetect signal indicating that the local station’s modem has detected incoming data signalling; 
equivalent to a signal presence indication. As a minimum requirement for compliance with this 
standard, the CLC shall employ a signal detector capable of detecting MIL-STD-188-110 serial 
tone modem signalling, including both the preamble and data portions of the modem waveform. 
As a design objective, it is also desirable that the signal detector be able to detect as many as 
possible of the signalling types corresponding to the traffic types enumerated in table C-XXXIV, 


as well as the following: 
e CW signalling 
e frequency shift keying (FSK) signalling. 
AudioDetect signal indicating that the local station has detected incoming audio (typically voice) signalling 
on the circuit link. The capability to detect SSB analog voice is a requirement for compliance 
pee | with this standard. 


ModemEORx signal indicating that the local station’s modem has detected the MIL-STD-188-110 serial tone 
End-Of-Message (EOM) sequence. 


ModemSigLoss signal indicating that the local station’s modem has declared signal absence after previously 
— having acquired an incoming modem transmission, without having detected the modem’s EOM 
sequence. 
AudioSigLoss signal indicating that the local station has determined that an incoming audio signal on the 
circuit link has ceased to be present. 
TrafficTimeout timeout event generated by TrafficTimer when the local station has not detected incoming or 


outgoing traffic on the current circuit link within an interval of duration > 
TRAFFIC_TIMEOUT_INTVL 


detected incoming or outgoing traffic transmission has expired. 
ReacqTimeout timeout event generated by ReacqTimer when the local station has not detected resumption of 
reception of an interrupted incoming modem or audio signal within an interval of duration > 


REACQ TIMEOUT INTVL. 
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TABLE C-LXV. CLC actions. 
Action name 


SetPriority Set TrafficPriority to the value of the prio parameter of a CLC_Active_Req or 
CLC_Set_Priority service primitive. 


StartTrafficTimer 
StopTrafficTimer 
StartBackoffTimer 
StopBackoffTimer 
StartReacqTimer 
StopReacqTimer 


U:CLC_Idle_ Ind Issue a CLC_Idle_Ind service primitive to the user process. 
U:CLC_Avail_Ind Issue a CLC_Avail_Ind service primitive to the user process. 
U:CLC_Busy_ Ind Issue a CLC_Busy_Ind service primitive to the user process. 


C.5.6.4.3 Data. 

Table C-LXVI defines the data items used and maintained by CLC, including buffers, counters, 
timers, configuration parameters, and so forth. These data items are referred to by the names 
assigned to them here, in the definitions of CLC events and actions presented in the preceding 
sections. These data items are used in this specification only as expository devices; it is not 
required for compliance that an implementation contain these data items in the form described 
here. 
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TABLE C-LXVI. CLC data items. 


BackoffTimer down-counting timer used to time BackoffTimeouts. Is set with a duration value 
and, unless reset before the timeout interval expires, counts down to zero, then 
generates a BackoffTimeout event. 

ReacqTimer down-counting timer used to time ReacqTimeouts. Is set with a duration value and, 
unless reset before the timeout interval expires, counts down to zero, then 
generates a ReacqTimeout event. 


TrafficTimer down-counting timer used to time TrafficTimeouts. Is set with a duration value 
and, unless reset before the timeout interval expires, counts down to zero, then 
generates a TrafficTimeout event. 

TRAFFIC_TIMEOUT INTV | constant configuration parameter: duration of the time interval after which a traffic 

L timeout will occur if no incoming or outgoing traffic is detected on the current 
circuit link. The value of this parameter is not stipulated as a requirement for 
interoperability. 

BACKOFF_ TIMEOUT _INTV | duration of the time interval after which a backoff timeout will occur if no 
incoming traffic is detected on the current circuit link. Determines the interval 
following each outgoing or incoming transmission on the circuit link during which 
the local station will listen for traffic on the circuit before transmitting. The 
interval duration is always zero for pending analog or digital voice traffic 
(preventing annoying delays in voice answer-back operation). For data traffic, the 
interval duration is selected randomly from one of five values; the relative 
probabilities of the possible duration values are determined by the priority level of 
the pending outgoing data traffic (if any), as specified in table C-LXVII. If no 
traffic is pending, the interval duration is set to zero. 

REACQ TIMEOUT _INTVL | constant configuration parameter: duration of the time interval after which a 
reacquisition timeout will occur if an incoming modem or audio traffic signal is not 
detected on the traffic circuit. The value of this parameter is not stipulated as a 
requirement for interoperability; a suggested default value is 800 milliseconds. 


TABLE C-LXVII. Backoff interval duration probabilities. 
___ Priority | Oms | 250ms | 450ms_ | 650ms __ 


P2P (after transmit or on —— 
start of link if not 

initiator) 

_ of link if Fan 


HIGH 1 
ROUTINE 
LOW 


The backoff scheme using these interval durations is intended to accomplish the following: 


e ona broadcast or multicast link, at the end of each transmission, stations having traffic 
of higher priority get earlier opportunities to seize the link. Mapping each priority level 


432 


MIL-STD-188-141B 
APPENDIX C 


to two backoff interval durations serves to reduce congestion when multiple stations 
have pending traffic at the same priority level. 


e TM PDUs (expected to be TM TERM ABORT or SIGN _OFF PDUs) are treated as 
being of priority equal to the HIGHEST priority level for user traffic. 


e Point-to-point traffic links are used fairly: at the end of each transmission, the receiving 
station gets the first opportunity to seize the link, based on the expectation that point-to- 
point link users will tend to want to send traffic in an alternating fashion. 


e When a circuit traffic link is initially established, the initiator of the link gets the first 
opportunity to transmit on it. 


C.5.6.4.4 Behavior definition. 
The state diagram in figure C-39 specifies the behavior of the CLC in terms of the events defined 
in C.5.6.4.1 and the actions defined in C.5.6.4.2. 


In the state diagram, each state transition is labeled with an event, an optional condition, and zero 
or more actions. This indicates that the state transition occurs whenever the event occurs and the 
condition obtains (is TRUE), causing the associated actions to be performed. In the diagram, 


e the name of each event is shown in square brackets preceded by the letter ‘E’; 


e the description of each condition is shown in square brackets preceded by the letter ‘C’; 
and 


e the names of the actions associated with a transition are shown in square brackets 
preceded by the letter ‘A’. 


Where a transition is labeled with two or more events, this indicates that the transition occurs 
whenever any of the events occurs. 
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Circuit Link 
Controller 


a 2 ON PSS E[D:CLC_Idle_Req] 

a 24 “ee PS - N A[StopReacqTimer] 

ra ae \ \ * 
ff E[TrafficTimeout] a 


C[circuit link initiator] E[D:CLC_Idle_Req] 


we vA A{StartTrafficTimer+ A[U:CLC_Idle_Ind] — A[StopTrafficTimer] ’ 
ff / SetPriority] | | \ 
a E[D:CLC_Idle_Req] \ | / 


\ 
E[D:CLC_Idle_Req] 


Pe DR 
E[ModemRTS] E[ModemDetect] 
E[AudioRTS] E[AudioDetect] | Y | 
AlStopTrafficTimer+ A[StopTrafficTimer+ | a | E[D:CLC_Active_Req(prio)] 
U:CLC_Busy_Ind] U:CLC_Busy_Ind] |  E[ModemDetect] ; C[NOT circuit link initiator] 
\ \ i \ | EfAudioDetect] Va A(StartBackoffTimer] 
E[D:CLC_Idle_Req] \ / \ | AlStopReacqTimer] / | | 
A[StopBackoffTimer] \ / \ 


E[ModemSigLoss] 
E[AudioSigLoss] 
E[BackoffTimeout] AlStartReacqTimer] 


A(StartTrafficTimer+ R 4 
U:CLC_Avail_Ind] eceive } 


4 
E[ModemEORx] 
A(StartBackoffTimer] 

/ 


/ / 
E[ModemEOTx] / / 
E[AudioEOTx] / 


, / E[ModemDetect 
A[StartBackoffTimer] | = ve aioDetect) ] E[ReacqTimeout] 


A[StopBackoffTimer] Apinacorine 


FIGURE C-39. CLC state diagram. 


In its Idle state, the CLC does not monitor link traffic or control access to the link. When a 
circuit link is established, the CLC of the station that initiated the link is placed in its Ready state 
and begins to monitor traffic on the circuit link. From Ready it proceeds to its Transmit or its 
Receive state, respectively, when outgoing or incoming traffic is detected. When the traffic ends, 
the CLC proceeds into its Backoff state where it waits for the duration of a backoff interval 
before returning to its ready state. If incoming signal presence is lost during reception of 
incoming modem signalling, the CLC enters its Signal Reacq state, where it remains until either 
incoming signal presence is reacquired, or a ReacqTimeout event occurs causing the CLC to 
decide that the incoming traffic has ended and proceed to its Backoff state. 


When a circuit link is established, the CLC of each station that did not initiate the link enters its 
Backoff state, giving the link initiator the first opportunity to transmit on the circuit link. 


Note that on the occurrence of any event not shown here, the CLC will take no action and remain 
in its current state. 
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C.5.7 Examples. 
Figure C-40 through figure C-45 illustrate the operation of the protocols described in this 


appendix. 


Normal ALE & TSU : 
(packet or point-to-point ckt 


Caller terminates: 


(abort or relink) = 
+ Frequency : 
t : 


Called terminates: 
(abort or relink) ; : 


LE_COMM 


TM_REQUEST receive failure: 1 {Exit Traffic 
(Relink due to no signal, : : : : { Frequency 
rcv failure, or unexpected PDU) : 


TM_CONFIRM receive failure: 
(Relink due to no signal, 
rcv failure, or unexpected PDU) 


+ Exit Traffic 
f Frequency 


FIGURE C-40. ALE/TSU scenarios: packet and point-to-point circuit links. 
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Normal ALE / TSU: 


(multicast circuit) 


ALE >< Roll Call 
(Once per control frequency) : (Traffic Freq) . 


Caller: aut _fecomeficoat come] 
(multicast addr. ): : 2 : : : : : 
Slot. , 
on a en ee a 


Slot 2: : : : : : : : : 


' Hard link multicast 


Slot N: : : ; : : : i : : : [ruconr | circuit link. 


Notes: 

¢ ALE shown is only the last 2 attempts before caller diverts to the traffic frequency. The ALE is repeated on all ca 
frequencies. 

* Caller responds in his own slot, based on his address. 

¢ If Slot k is not allocated, then no station shall respond in slot k. 

*N shall be known to all stations and, if possible, N shall include spare stations for late entry. 

¢ No other TM PDUs shall be transmitted until the TSU process has completed as shown. 


FIGURE C-41. ALE/TSU scenario: multicast circuit links. 


436 


TSU with ARQ 
(Until EOM or other exits 
as defined below) 


Normal EOM 
(# of xDL_EOMs must fit 
in xDL_DATA time slot) 


Caller Terminates 
via ABORT or RELINK 
(# of TM_TERM PDUs 


must fit in xDL_DATA time slot) : 


Called Terminates 
via ABORT or RELINK 
(during xDL_ACK time slot) 


Called misses xDL_DATA 
(i.e., unexpected PDUs 
or no response) 


Multiple missed xDL_DATA 
(Called issues TM_TERM 
(RELINK). “Many” is 

a vendor-defined qty) 


Multiple missed xDL_ACKs 
(Caller issues TM_TERM 
(RELINK). “Many” is a vendor- 
defined qty) 
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<— ALE >< TSU >< Traffic §$————> 


2 g Repeat : 
xDL_DATA oN : 
STxotack |! 

[xDL_EOM xDL_EOM |: 


frw_terw | | TERM _[TMTERM ' 


LE_CALL |: 


TM_CONF 


Exit Traffic ic 
Frequency only 
if packet connection 


Exit Traffic 
Frequency 


; Exit Traffic 
t Frequency 


Exit Traffic 
i Frequency 


; Exit Traffic 
, Frequency 


i 
+ Exit Traffic 
1 Frequency 


Pwo DATA —> fom] ITM |_ TERM rote | | TERM 


“Many 


FIGURE C-42. Packet traffic link termination scenarios. 


<— ALE —><— Tsu —><— Traffic 


2-Way Packet TSU 
(Until EOM or other exits 
as defined previously) 


Normal Switch-over: 


(# of xDL_EOMs must fit i int 
xDL_| DATA time slot) 


Notes: 


— 


> Repeat 


TM_REQ xDL_DATA a 
ee | CONF : 


inal oe 


Repeat 


« Anomaly scenarios and link exit criteria are the same as defined for one-way Packet TSU 


FIGURE C-43. Two-way packet link scenarios. 


437 


MIL-STD-188-141B 
APPENDIX C 


Normal TSU : 


Multicast 
circuit link 
Roll Call 


ALE 
<< 
: (Traffic freq) . 


_ (Once per 
: control freq) 


(multicast addr.): : : 


slot 0: 


Multicast ABORT 
(multicast address, 
ABORT cmd) 


Pt-to-Pt ABORT 
(specific address, 
ABORT cmd) 


Multicast sign-off : 
(multicast address, 
SIGN_OFF cmd) 


: |TM_TERM JTM_TERM |TM_TERM } Allstations 
: , * 4 exit traffic 


1 frequency. 
r 


v 7 
Both stations 
exit traffic: 
frequency. : 


Sender: 


Addressee: 


' exits traffic 


Sender: 
; frequency. 


FIGURE C-44. Link termination scenarios: multicast circuit links. 


438 


MIL-STD-188-141B 
APPENDIX C 


NOTE: This drawing is not to scale 


Caller Tx Control Frequencies Traffic Frequencies 
Called Tx 


Legend Control Control Control Control Traffic Traffic Traffic 
Freq Freq Freq Freq Freq Freq Freq 
1 2 3 4 1 2 3 


slot0 (LBT-T) 
slott 


Service Request: 
"Send_Pkt" ' 
“use: CF3" ; slot2 

Routine Priority slot3 


slot4 


slot0 (LBT-T) 
slott 
slot2 
slot3 
slot4 


slot0 (LBT-T) : : ‘ : i 


Caller: E 7 ‘ott : 
LE_Call PDU ' so : ; ; : i Caller: 
3G ARQ 5 LE_Call(2,5,ARQ) : ‘ : i Request Link 
from sta 2 to sta5 F LE_HS(#n,C,TF3) 8 y ' i Sta 2 to Sta5 
Called: : slot4 : : ° TM_Reg (2,5,H) High Rate DL 


LE_Handshake PDU ' slot0 (LBT-T) : 
Link id #n Fi : slott TM_Cnf (5,2,N) 


"Commence on TF3" : : jo ‘ P R Called: 
‘ : na : : Confirm Link 


slot3 i i Sta 5 to Sta2 
slot4 : ae no data to send 


ch) 
slot0 (LBT-T) B e Caller: 
slott z : Node 5 to n¢de 2 ; 


High Rate DL PDU 


packet data transfer 


slot2 on Traffic Channel 3 HDL_Ack (from 5) 


slot3 : i ' Called: 
slot4 : F i : High Rate Ack PDU 


HDL_Data . 
(to 5) : 


slot0 (LBT-T) : : : : : HDL_Ack (from 5) z 
slot1 . : ‘ 


a : : i ‘ HDL_EOM (2,5) 

ss : : : Caller: 
slot3 . : : i HDESEOM (23) Redundant 
= HDL_EOM (2,5) EOM PDU 
slot 


slot0 (LBT-T) : i : 
slott : ' Caller and Called: 
slot2 ' Return to Control 
Channel 
slot3 


slot4 


Caller: 
LE Call PDU slot0 (LBT-T) 


from sta 2 to Net : slott 
Link Release ' slot2 
: ‘ LE_Call(2,net,LR) 


Caller: LE_HS(#n,Rel, TF3) 
LE_Handshake PDU b 


Link id #n 
“Release TF3" 


slot0 (LBT-T) 
slott 
slot2 
slot3 
slot4 


FIGURE C-45. Packet linking and traffic exchange: on-air signalling overview. 
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APPENDIX D 


HF RADIO NETWORKING 
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APPENDIX D 
HF RADIO NETWORKING 
D.1 GENERAL. 
D.1.1 Scope. 


This appendix contains the requirements, prescribed protocols, and directions for the 
implementation of adaptive networking functions for high frequency (HF) radio. Networking 
represents the more advance technical capabilities of automated HF radio. 


D.1.2 Applicability. 
This appendix is a mandatory part of MIL-STD-188-141 whenever networking is a requirement 


to be implemented into the HF radio system. None of the features and functions described in this 
appendix are mandatory requirements for the user in the acquisition of an HF radio systems, 
however, if the user has a requirement for the features and functions described herein, they shall 
be implemented in accordance with the technical parameters specified in this appendix. 


D.2 APPLICABLE DOCUMENTS. 


D.2.1 General. 

The documents listed in this section are specified in D. 3, D. 4, and D. 5 of this standard. This 
section does not include documents cited in other sections of this standard or recommended for 
additional information or as examples. While every effort has been made to ensure the 
completeness of this list, document users are cautioned that they must meet all specified 
requirements documents cited in D. 3, D. 4, and D. 5 of this standard, whether or not they are 
listed. 


D.2.2 Government documents. 


D.2.2.1 Specifications, standards, and handbooks. 

The following specifications, standards, and handbooks form a part of this document to the 
extent specified herein. Unless otherwise specified, the issues of these documents are those 
listed in the issue of the Department of Defense Index of Specifications and Standards (DODISS) 
and supplement thereto, cited in the solicitation. 


STANDARDS 
FEDERAL 
FED-STD-1037 Telecommunications: Glossary of 
Telecommunication Terms 
DEPARTMENT OF DEFENSE 
MIL-STD-188-110 — Interoperability and Performance Standards for 
HF Data Modems 


MIL-STD-187-721 Interoperability and Performance Standards for 
Advanced Adaptive HF Radio 
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Unless otherwise indicated, copies of federal and military specifications, standards, and 
handbooks are available from the Naval Publications and Forms Center, ATTN: NPODS, 5801 
Tabor Avenue, Philadelphia, PA 19120-5099. 


D.2.2.2 Other Government documents, drawings, and publications. 

The following other Government documents, drawings, and publications form a part of this 
document to the extent specified herein. Unless otherwise specified, the issues are those cited in 
the solicitation. 


None. 


D.2.3 Non-Government publications. 


STANDARDS 


EIA/RS-485 Electrical characteristics of generators and receivers for use in 
balanced digital multipoint systems 


Application for copies should be addressed to the EIA, Engineering Dept., 2001 Pennsylvania 
Ave., N.W., Washington, D.C. 20006. 


ISO/IEC 3309:1991 Information Technology-Telecommunications and 
Information Exchange Between Systems-High Level Data 
Link Control (HDLC) Procedures-Frame Structure 


ISO/IEC 8824 Information Technology-Open Systems Interconnection- 
Specification of Abstract Syntax Notation One (ASN.1) 


ISO/IEC 8825 Information Technology-Open Systems Interconnection- 
Specification of Basic Encoding Rules for Abstract 
Notation One (ASN.1) 


Application for copies should be addressed to the International Organization for Standardization, 
Geneva, Switzerland. 


IEEE STANDARDS 


IEEE 802.2 Logical Link Control (LLC) and Medium Access 
Control (MAC) 

IEEE 802.3 Carrier Sense Multiple Access with Collision 
Detection (CSMA/CD) 
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Application for copies should be addressed to the IEEE, Inc., 345 East 47 Street, New York, NY 
10017. 


INTERNET DOCUMENTS 


RFC-768 


User Datagram Protocol 


RFC-1321 MDS Messafe - Digest Algorithm 

RFC-1441 Introduction to Version 2 of the Internet-standard 
Network Management Framework 

RFC-1442 Structure of Management Information for Version 2 
of the Simple Network Management Protocol 
(SNMPv2) 

RFC-1443 Textual Conventions for Version 2 of the Simple 
Network Management Protocol (SNMPv2) 

RFC-1444 Conformance Statements for Version 2 of the Simple 
Network Management Protocol (SNMPv2) 

RFC-1445 Administrative Model for Version 2 of the Simple 
Network Management Protocol (SNMPv2) 

RFC-1446 Security Protocols for Version 2 of the Simple 
Network Management Protocol (SNMPv2) 

RFC-1447 Party MIB for Version 2 of the Simple Network 
Management Protocol (SNMPv2) 

RFC-1448 Protocol Operations for Version 2 of the Simple 
Network Management Protocol (SNMPv2) 

RFC-1449 Transport Mappings for Version 2 of the Simple 
Network Management Protocol (SNMPv2) 

RFC-1450 Management Information Base for Version 2 of the 
Simple Network Management Protocol (SNMPv2) 

RFC-1451 Manager-to-Manager Management Information Base 
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RFC-1452 Coexistence Between Version | and Version 2 of the 
Internet-Standard Network Management Framework 


RFC-1570 Internet Official Protocol Standard 


RFC-1662 PPP in HDLC-Like Framing 


May be obtained by anonymous ftp from nis.nsf-net or nic.ddn.mil. 


D.2.4 Order of precedence. 
In the event of a conflict between the text of this document and the references cited herein, the 


text of this document takes precedence. Nothing in this document, however, supersedes 
applicable laws and regulations unless a specific exemption has been obtained. 


D.3 DEFINITIONS. 


D.3.1 Standard definitions. 
None. 


D.3.2 Abbreviations and acronyms. 
The abbreviations and acronyms used in this document are defined below. Those listed in the 
current edition of FED-STD-1037 have been included for the convenience of the reader. 


ACK acknowledge character 

ALE automatic link establishment 

ALQA Advanced Link Quality Assessment 

AME automatic message exchange 

ARQ automatic retransmission request 

ASCII American Standard Code for Information Interchange 
ASN.1 Abstract Syntax Notation One 

b/s bits per second 

BER bit error ratio 

CLNP Connectionless Network Protocol 

CONEX connectivity exchange 

CRC cyclic redundancy check 

CSMA/CD carrier sense multiple access with collision detection 
dB decibel 

DBM data block message 

DII Defense Information Infrastructure 

DoD Department of Defense 

DTM data terminal message 

HDLC high-level data link control 
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HF high frequency 
HFDLP HF Data Link Protocol 
HF MIB HF Management Information Base 
HFNC HF Networking Controller 
HFTP HF Transport Protocol 
HNMP HF network management protocol 
HRMP HF relay management protocol 
HSSP HF station status protocol 
ICMP Internet Control Message Protocol 
ID identification 
IP internet protocol 
LCP link control protocol 
LQA link quality analysis 
MRU Maximum Received Unit 
MSB most significant bit 
NAK negative-acknowledge character 
NRM Normal Response Mode 
NSAP network service access point 
OSI open systems interconnections 
P/F poll/final 
PIN personal identification number 
PPP point-to-point protocol 
QOS quality of service 
SDLP station data link protocol 
SINAD signal-plus-noise-plus-distortion to noise-plus-distortion ratio 
SNMP Simple Network Management Protocol 
SNMPv2 Simple Network Management Protocol version 2 
SNRM Set Normal response mode 
UA unnumbered acknowledge 
UDP User Datagram Protocol 
UTC universal time, coordinated 
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D.4 GENERAL REQUIREMENTS. 


D.4.1 Introduction. 
Networked operation supports indirect routing to deliver traffic when propagation does not 
support direct links. 


D.4.2 Networking controller. 
A networking controller performs the network-layer functions relating to traffic routing and 


relaying. In the simplest case, the network layer functions reside within a radio and have access 
only to the links achievable by that radio. A more advanced radio may include both ALE and HF 
data modems, along with a networking controller that is capable of establishing links using the 
ALE modem and protocols and is capable of switching to the data modem for data 
communication (see figure D-1). Such a networking controller could use either of the modems 
(via its respective data link layer entity) to carry traffic for the local user or to relay others’ traffic 
within the network. A still more sophisticated networking controller could manage several 
radios in a major communications hub, routing traffic through the radio that has the best path to 
the destination. Such a networking controller could be generalized to act as a multiple-media 
gateway, routing traffic over media such as wire, fiber, microwave, and satellite links as well as 
HF links. 


User ALE Controller 
Traffic etworking (incl. ALE Modem) | 
——— LL R/T 


Controller ' Data Modem 1 


and Controller 4s 


FIGURE D-1. Functional block diagram of an automated HF station. 


The principal functions performed within the networking controller are route selection and link 
selection, automatic message exchange (AME) and message store and forward, and connectivity 
tracking. Note that the connectivity tracking function employs the connectivity exchange 
protocol described in D.5.2.4 and the connectivity monitoring protocol described in D.5.2.6.6.3. 
The interactions among the various functions and data structures within the networking controller 
are shown on figure D-2. 


449 


MIL-STD-188-141B 
APPENDIX D 


Networking Controller 


Route 


Selection 
Routing 
Network 
Table 
Layer 


Path 
Link Connectivity 
Quality 


Selection Tracking 
Matrix 


Message Control Connectivity Data 


Data Link Controller(s) Data Link 
Layer 


FIGURE D-2. Networking controller. 


D.4.2.1 Data structures. 
Depending upon the level of functional capability of a networking controller (see D.4.2.6), it 
shall implement one or both of the following data structures. 


D.4.2.1.1 Routing table. 

The networking controller shall maintain a routing table that stores the preferred route from that 
station to other reachable stations (DO: also alternate routes); specifically, for each reachable 
station the routing table shall indicate how traffic destined for that station should be routed. 
Separate entries shall be maintained for voice and for data traffic. The routing table entries shall 
be individually programmable as static (entered manually by the operator or downloaded 
verbatim from other stations) or adaptive (computed automatically by the networking controller 
using the path quality matrix). See D.5.2.1.2 for detailed requirements for the routing table. 


D.4.2.1.2 Path quality matrix. 

The central data structure supporting adaptive routing is the path quality matrix. This matrix 
shall be organized to separately record voice and data path quality to any reachable destination 
via each directly-reachable relay station. These path quality estimates shall be based upon link 
quality measurements reported by the link controllers in accordance with D.5.2.1.1. 


D.4.2.2 Route selection. 
The route selection function routes voice and data traffic through networks using direct or 
indirect paths as required. While accomplishing this, it uses and maintains the routing table 
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discussed in D.4.2.1.1. The route selection function supports both indirect calling and various 
types of relaying, including analog repeaters, frame repeaters, and message store and forward. 


D.4.2.3 Message store and forward. 

The message store and forward function provides message delivery service for users or 
transport-layer processes (the term transport message is used in all cases). This function may 
buffer in-transit messages for varying periods of time depending upon the storage facilities 
available within the network controller. 


The store and forward process at each networking controller employs the route selection function 
to determine routes through the network for messages, and employs the automatic message 
exchange process to actually deliver messages over HF links. When full store and forward 
functionality is not required, a null store and forward function provides the interface to automatic 
message exchange (see D.5.2.5.3). 


D.4.2.4 Automatic message exchange (AME). 

Automatic message exchange refers to the network layer function that accepts network messages 
from the store and forward function for delivery to a specified directly reachable station (relay or 
final destination), and automatically delivers each message when a link is available to that 
station. When a link cannot be established to the requested station, the automatic message 
exchange function may either reject the network message, allowing the store and forward 
function to attempt delivery by alternate means, or it may store the message for future delivery 
when the desired link is established (so-called “discovery mode’). 


D.4.2.5 Connectivity exchange. 

Information about routes to stations that are not directly reachable, and which have not routed 
traffic through the local station recently, can sometimes be obtained from the connectivity data 
stored by a directly reachable station. This data may be shared either upon request or by periodic 
broadcast. When stations report their path quality matrix contents to other stations, this is termed 
connectivity exchange (CONEX). When, on the other hand, a station asks for replies from 
stations with connectivity to a specified destination this is termed query routing (e.g., “Who can 
reach Joe?’”’). Protocols for both functions are specified in D.5. 


D.4.2.6 Standard levels of capability. 
The standard levels of functional capability listed in table D-I are defined for HF Networking 
Controller (HFNC). Note that each level includes the capabilities of all lower-numbered levels. 


D.4.2.7 Link selection. 

The link selection function of the network controller shall interact with local data link controllers 
to request the establishment and status of links. It shall use data from the path quality matrix to 
select among available data link controllers for data transfer to the distant station. The link 
selection function makes no routing decisions per se. 
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TABLE D-I. Levels of HF networking controller functional capability. 


Level 1 Controls ALE radio (including indirect calling) 
Minimal HFNC Remote data fill support 
(No routing table) Automatic message exchange 
Null store and forward 
(No path quality matrix) Internet protocol (optional) 
Controls HF data modem (optional) 
Level 2 (All capabilities of Level 1 HFNC) -plus- 
Route selection using static routing table 
Basic HFNC Message store and forward 
Routing table data fill 
(No path quality matrix) Routing queries 
Repeater control (optional) 
Connectivity monitoring 
Controls multiple radios and modems (optional) 
Level 3 (All capabilities of Level 2 HFNC) -plus- 
Path quality matrix 
Adaptive HFNC Connectivity exchange (CONEX) 
Adaptive routing 
Level 4 (All capabilities of Level 3 HFNC) -plus- 
Routing via alternate media 
Multiple-media gateway Internet protocol (mandatory) 
Internet gateway 


D.4.2.8 Interface to link controllers. 

The following functions form a minimal interface between a networking controller and the link 
controllers that it uses. Because of the wide range of implementations possible, the specifics of 
this interface are not yet fully standardized. 


D.4.2.8.1 Link control. 

The networking controller shall be able to request the establishment and termination of links, 
specifying desired destinations using the appropriate link-level addresses. However, artifacts of 
particular link controllers (e.g., padding ALE addresses on the right with “@” characters) shall 
not be required of networking controllers. Link controllers should report the success or failure of 
link establishment and the identities of linked stations (e.g., stations responding to an ALE net 
call). 


D.4.2.8.2 Link quality reporting. 

The networking controller requires reports from the link controllers regarding the quality of links 
to other stations available from each link controller. These reports shall specify the data 
necessary for path quality matrix entries (e.g., BER and SINAD), but shall not contain data such 
as channel numbers that are relevant only to the link controller. 


D.4.2.8.3 Network messages. 

Messages to be sent from one networking controller to another over a link shall be delivered to a 
link controller in two parts: a network message (which is handled transparently by the link 
controller); and control information which specifies to the link controller the data-link layer 
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addressee of the message as well as other requirements for the transmission. The link controller 
is presumed to assume custody of each message that it accepts for transmission. Received 
messages delivered by link controllers to an HFNC shall be accompanied by the link layer 
address of the sender of the message. 


D.4.3 Interface to other media. 

The HF networking controller is capable of providing a subnetwork service to Internet routers. 
This subnetwork need not consist solely of HF links. When other media links are included in a 
subnetwork, the networking controller should route calls and traffic to optimize use of each type 
of link. 


D.4.4 Network management. 


D.4.4.1 Network management functions. 

Automated network management functions support the efficient control of automated HF 
networks. The tools for network management specified in D.5 include protocols for the 
following functions: 


a. Monitoring and reporting network status (e.g., topology, capabilities, congestion, and 
faults). 


b. Downloading ALE controller data. 


c. Updating network routing tables. 
d. Identifying software versions and updating the software in ALE and networking 
controllers. 


e. Re-keying linking protection scramblers. 

f. Remotely controlling station operations. 

g. Adjusting transmitter power of linked stations. 
h. Hand-off from ALE modems to other modems. 


i. Transition among security modes. 


D.4.4.2 Network management application program capabilities. 

The network management application program (often running on networking controller 
hardware) integrates the monitoring, reporting, and control capabilities of attached networking 
and link controllers to allow the network manager to view and adjust the operation of a network. 
These capabilities include the LQA, ALQA, Version, and Capabilities functions of the ALE 
controller, and the CONEX function of the networking controller. Network management 
programs employ the data communication capabilities of networking and link controllers to 
exchange network management messages. 
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D.4.4.3, Simple Network Management Protocol (SNMP). 

All HF radio equipment should implement the SNMP, as specified in Request for Comments 
1441-1452 (RFC-1441) with the HF-specific enhancement specified in D.5.3.2. This 
combination of SNMP with HF radio enhancements is hereafter denoted HF network 
management protocol (HNMP). Equipment not implementing HNMP may be managed through 
the use of proxy agents, which translate between HNMP commands and equipment-specific 
commands. 


NOTE: An HFNC is the platform for proxy agents because of its connections to most other 
equipment at a station. 


Every HFNC that implements HNMP shall also implement the HF AME protocol if carrying 
traffic over HF. 


D.4.5 Multiple-media networks. 
Multiple-media networks support the efficient integration of all available transmission media for 
end-to-end communications. 


a. From a user's perspective, a communication system should seamlessly integrate any 
available media to provide end-to-end service. In addition to this general requirement for 
static multiple-media interoperability, many Government systems (especially military and 
law enforcement agency systems) require robust networks that can sustain communications 
in the face of widespread loss of assets, and that can be rapidly extended into new locales 
using any available facilities. It is this dynamic element that distinguishes so called “any 
media” networks from the more common multiple-media networks. 


b. Because of the dynamic characteristics of ionospheric propagation, HFNCs are designed 
specifically to cope with fluctuating connectivity. This makes the HFNC especially suitable 
for service as a router in any-media networks. 


c. HF radio may be integrated with other media in two complementary ways: 


(1) A network of HFNCs may contain not only HF links, but also wireline, 
microwave, tropo- or meteor-scatter, and satellite links. Such HF networks use 
HF links for mobile or remote stations and for contingencies, with other media 
used as dictated by tactics and economics. 


(2) A network of HFNCs may serve as a subnetwork in a larger internet (such as 
the Internet). Such an “HF” subnetwork may of course employ any of the media 
listed above. The HF component of such internets provides an inexpensive means 
to extend the network to remote or mobile users. Examples include Defense 
Information Infrastructure (DII) entry and providing access to the commercial 
telephone system from remote regions of the world (e.g., northern Canada). 


When multiple media or any media networking is required, the other media shall be 
interconnected to HF assets via HFNCs. For fully automatic internetworking, the HFNC level of 
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functional capability must be level 2 or above (see table D-I). A level 4 HFNC is required for 
internet gateways in the case of paragraph D.4.5.b above. 


D.5 DETAILED REQUIREMENTS. 


D.5.1 Introduction. 
HF networking technology includes HFNC functions, the HF Network Management Protocol, 
and a data link protocol for use within automated HF stations. 


D.5.2 Networking functions. 
The functions implemented within a networking controller include automatic route and link 


selection, indirect calling, connectivity monitoring, connectivity exchange, routing queries, 
repeater control, message store and forward, automatic message exchange, and station status 
reporting. 


D.5.2.1 Route and link selection. 

The router is the central entity of the networking controller, in the sense that almost every other 
networking function either relies upon it or supports it. The router performs two functions: route 
selection and link selection. The route selection function finds routes through networks for user 
and orderwire traffic, using connectivity data from the path quality matrix, operator entries, and 
broadcast queries to maintain the routing table. The link selection function simply chooses the 
best data link available to each destination selected by the route selector. 


The following examples of network-layer operations refer to the hypothetical network 
connectivity from station A shown on figure D-3. The arrows indicate the direction(s) of 
connectivity; the pair of numbers on each arrow indicates voice and data path quality, 
respectively (in accordance with the link quality functions in MIL-STD-187-721, paragraph on 
Link Quality Functions). 


455 


MIL-STD-188-141B 
APPENDIX D 


FIGURE D-3. Network connectivity example. 


D.5.2.1.1 Path quality matrix. 
The path quality matrix is organized with a row for each directly reachable relay station, and a 


column for each destination of interest. When multiple data link controllers are available to the 
networking controller, a separate path quality matrix may be maintained for each, or a single path 
quality matrix may be maintained. The single path quality matrix contains the best path scores 
over all link controllers, along with indications of the specific link controller to use for each path. 


A path quality matrix is needed by every networking controller that provides adaptive routing for 
locally-originated messages, whether or not the station intends to relay messages for other 
stations. 


Figure D-4 illustrates how the network connectivity on figure D-3 may be summarized in the 
path quality matrix at station A. The path qualities are computed in accordance with the 
algorithms given in D.5.2.4.1 and D.5.2.4.2. Note that unidirectional path qualities (A to 
destination) are shown. Normally, path qualities in both directions will be stored and used. 
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FIGURE D-4. Path quality matrix example. 
D.5.2.1.2 Routing table. 
A routing table is maintained by the networking controller for use in route selection. An example 
routing table is shown on figure D-5, corresponding to the path quality matrix example on figure 
D-4. 


457 


MIL-STD-188-141B 
APPENDIX D 


ROUTE VOICE 
TRAFFIC VIA * 


ROUTE DATA 
TRAFFIC VIA * 


*KEY: 
Relay Address 
Path Quality 
Relays 

Age 


FIGURE D-5. Routing table example. 


D.5.2.1.2.1 Organization. 

The routing table is organized for quickly determining where to send traffic destined for any 
reachable station. It is indexed by a reachable station address. The entry for each station 
contains (at least) the best relay(s) for voice and data traffic destined for that station. In addition, 
routing table entries may contain alternate relays and candidates for indirect calls when no relays 
are available. 


D.5.2.1.2.2 Manual entries. 

A means shall be provided for operator entry of routing table data. These entries shall be 
retained in non-volatile storage when the network controller is powered off and shall not be 
overwritten by automatic updates to the routing table from path quality matrix data; this may be 
implemented by flagging non-adaptive routing table entries. The operator shall also be able to 
view, edit, and delete manual routing table entries. The requirements of this paragraph do not 
apply when the mission, power, or weight limitations contraindicate. 


D.5.2.1.2.3 Automatic updates. 
When adaptive routing is employed, alternative routes to reachable destinations shall be 


re-evaluated whenever new path quality data arrives (e.g., via CONEX), and the routing table 
shall be updated as appropriate. 
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D.5.2.2 Indirect calling. 
When a link controller fails to establish a link requested by the networking controller, the routing 


table (and path quality matrix as required) may be used to identify candidate station(s) for 
indirect calling. Initiation of an indirect call by the networking controller may be automatic upon 
linking failure or it may be initiated by the operator. When an automatic indirect call succeeds in 
establishing a link with a candidate station, the operator should be notified that the link 
established is to a third party rather than to the desired destination. 


D.5.2.3 Network layer header. 

All messages sent from one networking controller to another shall be preceded by a single ASCII 
character denoting the type of message to follow. When a networking controller receives a 
message, it examines this one-character header to determine the format and protocol to use in 
interpreting the remainder of the message. (See D.4.2.) 


The defined network layer header characters are listed in table D-II. Header characters not listed 
are reserved and shall not be used until standardized. 


TABLE D-II. Network layer header characters. 


Connectivity exchange 


User message (with AME header) 


Relay management 


Station status message 


D.5.2.4 Connectivity exchange. 

The CONEX protocol allows relay stations to exchange lists of other stations they can contact. 
However, CONEX exacts a price in overhead channel usage that may be unacceptable under 
many conditions. Normally, relay stations use static routing table entries with notification-based 
protocols (see D.5.2.6.6.3 and D.5.2.7) and HF network management requests. CONEX is useful 
only for those relay stations equipped with a Level 3 or 4 HFNC (see table D-I), and is 
recommended only for those networks that cannot use normal routing table maintenance (also see 
D.5.2.4.1b). 


a. Networking controllers exchange the contents of their path quality matrices using the 
following CONEX protocol. Note that CONEX messages may be carried on any type of data 
link that connects the parties to the exchange. Because these messages may be relatively 
large, a high speed modem should be used for CONEX whenever possible; the ALE modem 
should only be used when no other data link is available. 


b. A CONEX report pertains to the path from one station to another, which may consist of a 
single link (a “direct path”) or of multiple links (an “indirect path’) through one or more 
intermediate (relay) station(s). In all cases, each CONEX report includes the number of relay 
stations included in the path, estimates of the path quality for voice and for data, and the age 
of the oldest data used to estimate these path qualities. 


459 


MIL-STD-188-141B 
APPENDIX D 


D.5.2.4.1 Voice path quality. 

The voice quality for a path is an estimate of the end-to-end SINAD of the path. For SINAD less 
than 2 dB, the voice path quality is 0; for 2 through 26 dB, the quality is 1/2 SINAD (in dB); for 
SINAD greater than 27 dB, the quality is 14; and when the end-to-end SINAD is unknown, the 
quality is 15 (1111) (default value). Voice quality shall be computed as follows: 


a. For a single-link path, the mean SINAD for that link (median SINAD if ALQA data is 
available) shall be obtained from the link controller and converted directly to a path quality 
code. 


b. For a multilink path, the voice quality obtained in a CONEX report from the best relay 
station for the ultimate destination shall be combined with the quality of the best link to that 
station to obtain the resulting voice path quality as specified in table D-III. (Note that a 
multilink path will never have quality 14.) The “best relay” is the station among all potential 
relays that gives the highest result quality after the qualities of links to those stations have 
been included. 


D.5.2.4.2 Data path quality. 


a. The data quality for a path is an estimate of the efficiency of the path in passing data 
traffic. The data path quality code used is based upon estimates of the time required to pass 
messages over each link in the path; the resulting code reflects several measures of 
importance to data networks: data throughput, message latency, and resource utilization 
(stations and channels). 
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TABLE D-III. Voice path quality cascading. 


Result Result 
Quality 1 Quality 2 Quality Quality 1 Quality 2 Quality 
a eee (ea a |S | ee | es 
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b. Computing the end-to-end data path quality through one or more relay stations shall proceed 
as follows. Assume that station “A” receives a CONEX report from “B” about the best data path 
from “B” to “X.” Station “A” computes its path quality to “X” through “B” by combining the 
quality of its link to “B” with the report from “B” about “B’s” best path to “X:” 


(1) Station “A” computes the quality of its link to “B” as described in paragraph e below, 
and compares the result to the quality of the path from “B” to “X” as reported by “B.” 


(2) If either quality is 0, the result is 0. Likewise, if either is 31 (unknown), the result is 
31 


(3) In all other cases, the quality of the path from “A” to “X” through “B” is 1 less than 
the lower path quality of the two components. 


c. The quality of a single data link is computed from the nominal data rate and measured 
error characteristics of that link obtained from the link controller. The result of the following 
formula shall be truncated to an integer in the range of 0 through 30, inclusive (e.g., if the 
result is less than zero, 0 shall be used). 


Data link quality = 7 + Nominal Speed - ARQ Repeats. 


d. The “nominal speed” term in the formula is obtained from the nominal data rate (in bits 
per second (b/s)) as follows. The result shall be rounded to the nearest integer. Note that the 
logarithm is taken with a base of 2. 


Nominal speed = log, (data rate/75 b/s). 


e. The “ARQ repeats” term in the formula is the mean number of error-induced 
retransmissions per message of the messages sent over that link during the past hour. If no 
messages were sent over the link during the past hour, the ARQ repeats term may be 
estimated using the BER of the link (measured before error correction): 


BER ARQ Repeats Estimate 
<0.1 0 
0.1< BER < 0.199 BER - 0.1 
0.2 - BER 
> 0.199 100 (link unusable) 


Table D-IV illustrates the use of this formula: 
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TABLE D-IV. Examples of data path quality computations. 
Nominal Data} Nominal ARQ Repeats ARQ Repeats | Data Link 
Link Type Rate Speed (measured) (estimated) oem 
DTM 53.6 
(ALE Modem) 53.6 0.1181 


eee eh ee II 

Modem 2400 5 0.167 

ee ee ee eee a ee 
Modem 9600 7 1.2 12 


D.5.2.4.3 CONEX message format (Optional). 


a. A CONEX message consists of a header, identifier(s) of the net or specific stations 
reported, and reports of path quality to those stations. When a net is named, the reports for 
the stations in the net are listed in the standard order for that net, without sending the 
individual station identifiers. A flow diagram for the structure of a CONEX message is 
shown on figure D-6. CONEX messages are formatted in even multiples of 8 bits to 
simplify the insertion of these reports into the natural data blocks of the links likely to be 


available. 
Bas ID 


baton ID 


FIGURE D-6. Structure of CONEX message. 


b. The CONEX message header contains a 16-bit Control field, followed by the name of the 
sending station, as shown on figure D-7. The first bit is set to 1. The second bit is set to 1 to 
request CONEX from responding stations, or to 0 to suppress such responses. The third bit 
is set to 1 to indicate that CONEX reports follow the sending station name; if this bit is 0, no 
reports are included in this message. The next five bits in the Control field contain a count 
of the characters in the sending station name (a count of 0 indicates a 32-character address). 


The second 8 bits of the header begin with 2 bits set to 1 and 0 respectively, followed by the Max 
Age and Max Relays fields. The Max Age and Max Relays fields apply to CONEX requests; the 
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responding station shall only return reports whose Age and Relays fields do not exceed these 
limits (all 1’s in a field means no limit). The Control field is followed by the number of ASCII 
characters indicated in the Count field, with a 0 most significant bit (MSB) placed before each 7- 
bit character. 


Control Field 


Count Field Max Age Max Relays | Sending Station Name (7-Bit ASCII Characters Plus 0 MSB) 


AN hie Pag thea Ubi 


| Reports to Follow 
Request CONEX Response 


FIGURE D-7. CONEX header. 


c. Station and network IDs have a structure similar to the CONEX header. Each begins with 
an 8-bit Control field, which is followed by the ASCII characters composing the name of that 
station or network (see figure D-8). The first bit is set to 1. The second bit is set to 0 for an 
individual station identifier, and to | for a network identifier. The third bit is set to 0 in the 
last ID in the CONEX message, and to | for all of the preceding station and network IDs. 
The last five bits in the Control field contain a count of the characters in the station or 
network name. The Control field is followed by the number of ASCII characters indicated in 
this count, with a 0 MSB placed before each 7-bit character. 


Control Field 
Count Field Sending Station Name (7-Bit ASCII Characters with 0 MSB) 


More IDs to follow 


0 for individual station ID 
1 for network ID 


FIGURE D-8. CONEX station or network ID. 


d. Each report ina CONEX message refers to the best path from the sending station to a 
specified destination. When the report is preceded by a station ID, the report pertains to the 
best path to that station. When the report is one of a sequence of reports following a network 
ID, the destination station is known implicitly from the position of the report in that 
sequence. 


e. Each report contains four fields as shown on figure D-9: the minimum number of relays 
between the sending station and the destination station (3 bits); end-to-end quality of the best 
path(s) to the destination for voice or data use (4 bits for voice quality and 5 bits for data 
quality); and the age of the oldest data used to compute the voice and data path qualities (3 
bits). Note that the first bit is always set to 0. 
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Voice Quality Age Data Quality Relays 


FIGURE D-9. CONEX report. 


f. The Age field uses the encoding as shown in table D-V. For 0 through 5 relays in the 
path, the Relays field contains the number of relays. For 6 or more relays, the Relays field 
contains 110 (6). When the number of relays is unknown, the Relays field is set to 111 (7). 


TABLE D-V. Age field encoding. 


0 - 15 min 
15 - 30 min 
30 - 60 min 


1-2hr 

2-4hr 

4-23 hr 

23 - 25 hr 
>25 or unknown 


D.5.2.4.4 CONEX broadcast. 


a. Stations may periodically broadcast CONEX messages containing reports of path quality 
to selected destinations (e.g., net control stations, gateways to other networks, or distant 
network members that are difficult for some members to reach). The rate of such broadcasts, 
the channels used, and the stations included in the CONEX report may be selected by the 
operator or may be determined adaptively by the networking controller. A CONEX 
broadcast will typically use an ALE scanning call to a net or group. The CONEX message 
may be sent using DTM or DBM with the ALE modem; however, an HF data modem should 
always be used when available. 


b. A station receiving a CONEX broadcast should update its path quality matrix using the 
data received along with link quality data from the link controller receiving the broadcast, as 
described above. 


D.5.2.4.5 CONEX handshake. 

A CONEX handshake is used to exchange connectivity data among networking controllers. The 
request bit is set to 1 to request connectivity, and the Max Age and Max Relays fields may be 
used to restrict the number of reports received. ALE is used to establish the link(s) used, as 
required; the CONEX messages may be conveyed using either the ALE modem (with DTM or 
DBM) or a data modem. 
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D.5.2.5 Message delivery. 

In the seven layer reference model, the network layer performs end-to-end message delivery, 
using one or more data links in tandem to carry each message. When HF links are employed, the 
inherent error rates involved require the use of connection-oriented data links for efficient use of 
the medium. Such data link protocols guarantee that those blocks of a message that are delivered 
to the network layer at the destination arrive in order and without duplication. (The DTM and 
DBM ALE protocols using CRC and ARQ satisfy these requirements, as do other data link 
protocols used in advanced modems.) 


However, data links occasionally fail, so the data link layer cannot guarantee message delivery 
within a bounded time. A mechanism is required at the network or transport layer to detect and 
deal with data link failures through the use of retransmission, alternate routing, etc. In the 
existing DoD internet, this function is performed in the transport layer. Therefore, the HF 
network layer need only provide datagram service, and its principal function is message routing. 


D.5.2.5.1 AME header. 

The AME header (see D.4.2.4) carries the information used by the network layer for message 
routing and delivery. This header immediately follows the single-character network layer header 
(which will be ‘M’ to indicate that an AME header follows). The AME header contains the 
following fields: 


Quality of A single bit indicating whether to emphasize 

Service (QOS) speed of delivery (QOS = 0) or minimum probability of loss or error 
(QOS = 1) in handling the message. 

Precedence A 3-bit code with 0 as lowest precedence. Used for queuing at relay 
nodes and determining order of link establishment, order of delivery, 
etc. 

Port A 4-bit code designating destination port within network controller, 


analogous to network service access point (NSAP) in the seven layer 
model. Assigned port numbers are listed in table D-VI. 


Header Length An 8-bit count of the bytes in the AME header, starting with the 
precedence/port byte and ending with the last character of the source 
address record. 


Message Length A 16-bit count of the bytes in the transport message following the 
AME header (does not include the network layer header or AME 
header bytes). 


Relay(s) Zero or more address records (see address record format description). 
When relays are specified, they may be either suggested relays or 
mandatory relays. When mandatory relays are specified, the message 
must be routed through the relays listed in the order given. Suggested 
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relays are offered for consideration by the route selector in addition to 
alternatives found in the routing table. 


Destination(s) One or more address records. The message body should be delivered 
to all destination addressees. 


Source One address record, specifying the address of the station that 
originated the message. 


An address record is structured as an 8-bit flag, followed by a network layer address of ASCII 
characters with a 0 MSB placed before each 7-bit character. The MSB of the flag is a 1. The 
next two bits encode the record type: 0 for a source address record, | for a mandatory relay, 2 for 
a suggested relay, and 3 for a destination. The five least-significant bits contain a count of the 
characters in the address. Address characters have MSB = 0. An example of an AME header 
and address record is shown on figure D-10. 


TABLE D-VI. Port numbers in AME header. 
Transport Message Destination 


Operator Terminal 
Automatic Message Exchange Control Channel 
Operator Storage 
HF Transport Protocol (HFTP) 
Connectionless Network Protocol (CLNP) 
Internet Protocol (IP) 
HF Network Management Protocol (HNMP) 
Il Others Reserved Until Standardized 


QOS Precedence Port Header Length eT Length 
(1) (3) (4) (8) 16) 


Message Header 000 0000 00001100 0000000000000111 


se Network-Layer Address (7-Bit ASCII Plus MSB=0) 
Destination 


ddress O E 
Record 01001010 01001111 01000101 


Network-Layer Address (7-Bit ASCII Plus MSB=0) 
Source 


Address S) A M 
Record 01010011 01000001 01001101 


FIGURE D-10. Example AME message header and address record. 


D.5.2.5.2 Message store and forward. 
The store and forward process accepts messages from, and delivers messages to, users (or 


transport-level processes). Each transport message to be sent is accompanied by the network 
layer addresses of its destination(s). For each transport message to be sent, the store and forward 
function groups the network layer destination address(es) according to the first relay on the path 
to each addressee (obtained from the route selection function), or the final destination if a direct 
path is the best path. For each such group, an AME header is formed. The header contains the 
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destinations that share an initial relay station. The transport message is appended to this header 
to compose a network message. These network messages are passed to the local AME process 
for delivery. 


As network messages arrive from other stations and are delivered to the store and forward 
function by the local AME process, the AME header of each is removed and processed as 
follows: 


a. If any of the destination addresses in the header are self addresses, the embedded transport 
message is delivered locally as specified in other fields (precedence and port) of the header. 


b. All self addresses are removed from the header. 


c. If any destinations remain, those addresses and the transport message are handled as 
discussed above for a new outgoing message. 


D.5.2.5.3 Null store and forward function. 

A null store and forward function may be used in place of the message store and forward process 
described above when automatic message routing is not needed. The null store and forward 
function shall form AME headers for outgoing messages and process the AME headers from 
incoming messages as follows. 


D.5.2.5.3.1 Outgoing messages. 
For each outgoing message, the null store and forward function shall create an AME header with 


pre-programmed values in all fields, except that the header length and message length fields shall 
be computed for the actual message and AME header. The user (or transport layer process) shall 
be able to override the default values. Normally, the user will override only the default 
destination address, the precedence, and the port fields. A user may insert relay addresses for 
manual source-routing. Ifthe user is able to override the source address, this capability should 
normally be restricted to selecting one of a set of pre-programmed addresses (to preclude 
impersonation of other stations). 


D.5.2.5.3.2 Incoming messages. 
The destination and relay address records in the AME header of each incoming message shall be 


examined. Ifa self address is found in any of these address records, the message and the AME 
header shall be delivered to the user. (This permits users to manually relay messages.) 


D.5.2.5.4 AME. 

AME is the network layer function concerned with single-link message delivery. It works with 
either a full store and forward process or a null store and forward process. In the following 
paragraphs, the term “store and forward process” refers to either implementation of the store and 
forward functionality. 


NOTE: AME provides a simple datagram service, with no acknowledgments, error 
checking, or flow control. 
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D.5.2.5.4.1 Outgoing messages. 

Each network message passed to the AME process from the store and forward process contains 
an AME header and a transport message. The AME process shall interpret the first address 
record in the AME header as the desired destination for that message. 


Outgoing messages from the store and forward process shall be queued by the AME process for 
transmission in order of precedence. The AME process requests a link to the destination of each 
message from the link selection function. When the link selection function indicates that a link 
to that destination is available, the AME process shall attach a network layer header (the 
character “M’’) to the front of the message, translate the network layer address to a data link layer 
address appropriate for the selected data link controller, and provide the network message and the 
translated address to that controller for transmission. 


If a direct link cannot be established to the destination, the AME process shall take one of two 
actions: 


a. Return the message to the store and forward process as undeliverable (appropriate if the 
store and forward process can attempt alternate routing). 


b. Store the message for later delivery when a link can be established. 


In the latter case, messages should be stored in separate queues for each destination so that only 
one series of linking retries is made for each destination (rather than one for each queued 
message). The first retry shall be made after a time sufficient for a busy station to have resumed 
listening for linking attempts. To minimize use of the spectrum for futile linking attempts, 
subsequent retries shall occur at intervals sufficient for propagation to have measurably 
improved. (The retry interval may be shortened when a queue contains high-priority messages.) 


When contact is eventually made with the desired destination, whether through a successful 
linking retry or through connectivity discovered by reception of a message from that station, 
messages queued for that destination shall be sent in decreasing priority order. 


D.5.2.5.4.2 Incoming messages. 

Incoming messages are delivered to the AME process when their network layer header is “M” 
(user messages). The AME process shall simply strip this single-character network layer header 
and pass each received message to the store and forward process for processing. 


D.5.2.6 Relay management protocol. 

The HF relay management protocol (HRMP) shall be used by HF networking controllers to 
inquire about connectivity through prospective relay stations, to manage repeater operation, and 
to preempt repeater circuits, as described in D.5.2.6.6. HRMP is a connectionless protocol, 
although it can be used to set up analog tandem circuits or data virtual circuits. 


Every HRMP message refers to three stations: the first is the Relay station (actual or potential); 
the second is the Control station managing the relay; the third is the Distant station to which 
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access is provided by the relay. HRMP messages are exchanged between the Control station and 
the Relay station. 


HRMP messages shall be formatted as shown on figure D-11. The fields in HRMP messages 
shall be encoded as described in the following paragraphs. 


Msg. Msg. Desired | Msg. | Msg. 
Dest. | Source | Dest. ID Length | Command | Arguments | Checksum 


FIGURE D-11. HF relay management protocol message format. 


D.5.2.6.1 HRMP address field. 

Three station addresses are present in every HRMP message: that of the station sending the 
message (Msg. Source), that of the station to which an indirect path is sought or desired (Desired 
Dest.), and that of the station receiving the message (Msg. Dest.). The Desired Dest. shall always 
be the Distant station. The Msg. Source and Msg. Dest. shall be the Control and Relay stations, 
respectively, for Control-to-Relay messages, and vice versa for Relay-to-Control messages. 


The addresses of all three stations shall be encoded as AME address records in accordance with 
D.5.2.5.1. 


D.5.2.6.1.1 Message destination. 
The Msg. Dest. field on figure D-11 shall contain the address of the Relay station, with a 


suggested Relay flag, when the message direction is Control-to-Relay. For Relay-to-Control 
messages, the Msg. Dest. field shall contain the address of the Control station with a source flag. 


D.5.2.6.1.2 Message source. 
The Msg. Source field on figure D-11 shall contain the address of the Control station, with a 


source flag when the message direction is Control-to-Relay. For Relay-to-Control messages, the 
Msg. Source field shall contain the address of the Relay station with a suggested Relay flag. 


D.5.2.6.1.3 Desired destination. 
The Desired Dest. field on figure D-11 shall always contain the address of the Distant station, 
with a Destination flag. 


D.5.2.6.2 HRMP message identification field. 
The Msg. ID on figure D-11 field shall contain an 8-bit number used by the Control station to 


match responses with requests. Responses from the Relay station shall contain the same Msg. ID 
as is found in the corresponding Request from the Control station. Messages from the Relay 
station other than responses shall set this field to all Is. 


D.5.2.6.3 HRMP length field. 


The Msg. Length field on figure D-11 shall contain the number of bytes in the entire HRMP 
message, from the first byte of the Msg. Dest. field through the last byte of the Checksum. 
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D.5.2.6.4 HRMP commands. 

The HRMP command field on figure D-11 shall contain one of the 8-bit codes listed in table 
D-VII. (Unlisted codes are reserved and shall not be used until standardized.) The use of these 
commands is described in D.5.2.6.6. 


TABLE D-VII. Relay management commands. 


ACK (None) 

Query Type, QOS, precedence 
Query-response Type, QOS, precedence 
Connectivity-change Connectivity code 
Monitor-connectivity Cx Monitor 


Repeater-status Rept. No., type, QOS, status 
Repeater-request Type, QOS, precedence 
Repeater-lost Rept No., reason code 
Repeater-status-request Repeater number 
Release-repeater Repeater number 

NAK Reason code 


The encoding of the arguments to these commands is given in table D-VIII. (Unlisted codes are 
reserved and shall not be used until standardized.) Arguments shall be sent in the order listed in 
table D-VIII. 
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TABLE D-VIII. Encoding of HRMP arguments. 


Reason code 8-bit unsigned 0 - No connectivity 
1 - Precedence too low 
2 - Inappropriate 
255 - Not equipped 
Type 2-bit unsigned 0 - Analog repeater 
1 - Digital repeater 
(Usually frame repeater) 
2 - Store and forward 


6-bit field Each bit independently selects a quality-of-service aspect; if bit = 1, 
better than normal performance in this aspect is requested 
QOS1: (MSB) Delay 
QOS2: Throughput 
QOS3: Reliability 
QOS4: Noise 
QOSS: (Reserved) 
QOS6: (LSB) (Reserved) 
Precedence 8-bit unsigned 0 - Routine (lowest) 
64 - Priority 
128 - Immediate 
192 - Flash 
250 - Flash override 
254 - Reserved for inter-network control use 
255 - Reserved for network control use* 


Connectivity 8-bit unsigned 0 - Discovered direct connectivity 
1 - Discovered indirect connectivity 
254 - Lost direct connectivity (have indirect) 
255 - Lost all connectivity 
0 - Broadcast all changes of connectivity to distant stations 
insane 1- Broadcast only lose or discovery of connectivity: 
do not report transactions between direct and indirect 


128 - Report all changes in connectivity 
129 - Do not report connectivity changes 


Repeater No. 8- Eee | 8-bit unsigned | Repeater reference number assigned by relay station 


Status 8-bit 0 - Repeater fully operational 
unsigned 1 - Requesting link to distant station 
2 - Link to distant station failed; attempting to re-establish link 
3 - Repeater preempted 
255 - Repeater not available 


* NOTE: Any number from | through 253, except those standardized herein (0, 64, 128, 192, and 250) may be 
used for user unique precedence requirements. 
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D.5.2.6.5 Checksum. 
The 16-bit Checksum shall be computed in accordance with D.5.2.9. 


D.5.2.6.6 HRMP operation. 
Allowed exchanges are listed in the following paragraphs for each of the classes of relay control 
actions supported by the HRMP. HRMP exchanges are one of two types: 


a. Request-response. A control station sends a request to a Relay station and starts a timer. 
If a response is received before the timer expires, the protocol completes successfully. 
Otherwise, the Control station should abort the exchange. Lack of a response indicates loss 
of connectivity to the Relay station; thus, a retransmission should not be initiated until 
sufficient time has elapsed for connectivity to be restored (either improved propagation or 
resumption of operations at the Relay station). 


b. Notification. A Relay station sends an unsolicited message to a Control station to 
announce an event asynchronously. Such events include preemption of a repeater in use by 
the Control station or loss of connectivity to a Distant station being monitored at the request 
of the Control station. 


D.5.2.6.6.1 Routing queries. 
A station seeking to find an indirect path to a Distant station sends a query to prospective 
relay(s). A station receiving a query shall respond with a NAK in any of the following cases: 


a. It lacks the facilities to provide the services requested (reason code = not equipped). 


b. It has facilities, but they are not available for a request of the stated precedence (reason 
code = precedence too low). 


c. It has available facilities, but has no connectivity to the requested Distant station (reason 
code = no connectivity). 


A station having available facilities that at least approximate the requested service and having 
connectivity to the requested Distant station, shall return a query response that describes the type 
and quality of service it can provide. Note that routing queries may be made for either message 
store and forward service or repeater service. 


D.5.2.6.6.2 Repeater control. 

Both analog and digital repeaters may be remotely controlled through the use of the Repeater 
control commands. When a repeater is engaged using HRMP, the Relay station shall assign a 
repeater number (analogous to a virtual circuit number) for unambiguous reference to the circuit 
established. 


a. A repeater request shall specify the type and quality of service desired (just as in a query). 
If the repeater can be engaged, the Relay station shall return a repeater status response which 
contains the assigned repeater number and type and quality of service actually provided. 
Otherwise, (see conditions in D.5.2.6.6.1) a NAK shall be returned. 


473 


MIL-STD-188-141B 
APPENDIX D 


NOTE: A repeater request specifying store and forward shall elicit a NAK with a reason 
code of “inappropriate” because the store and forward function cannot be seized. 


b. A repeater status request sent by a Control station to inquire about the operational status 
of a previously engaged repeater shall carry the repeater number assigned when it engaged 
that repeater. The Relay station shall respond with a NAK if the specific repeater is not 
currently assigned to the Control and Distant stations specified in the message; otherwise, it 
shall respond with a repeater status message that describes the type, quality of service, and 
current status of the specific repeater. 


c. A Control station shall release an engaged repeater by sending a release repeater message. 
The Relay station shall send a NAK under the conditions described above for repeater status 


requests; otherwise, the Relay station shall terminate the link to the Distant station, 
disengage the repeater, and return a repeater status message containing a status code of 
“repeater not available.” 


d. When a Relay station cannot sustain a previously engaged repeater service, it shall send a 


repeater lost message to the affected Control and Distant stations. For each intended 


recipient of the repeater lost message, the address of that station shall be encoded as the Msg 


Dest using a source address record, and the third party to the repeater service shall be 
encoded as the Desired Dest using a Destination address record. If the repeater service is 


terminated because of loss of connectivity, the reason code shall be “no connectivity.” Ifthe 


repeater was preempted, the reason code shall be “precedence too low.” 


Loss of a link to one party of a repeater service shall not result in a repeater lost message and 
termination of the repeater service until attempts to automatically re-establish the link have 

failed. During link re-establishment, the repeater status shall be reported as code 2 in responses 
to repeater status requests. 


D.5.2.6.6.3 Connectivity monitoring. 


Connectivity monitoring is a notification-based alternative to connectivity exchange (D.5.2.4). A 


Monitor Connectivity message requests that the named Relay station monitor (or cease 
monitoring) its connectivity to the named Distant station. Notification options include 


broadcasting connectivity changes to all stations, or reporting changes to a named control station, 


or cease reporting changes in its ability to reach that Distant station. If the Distant Station field 
contains the network broadcast address (D.5.2.8), the Relay station shall perform the indicated 
command for all stations. 


Notification of a change in connectivity shall be sent in a connectivity change message. A 


connectivity change message may be broadcast by addressing it to the network broadcast address 


(D.5.2.8). The arguments defined for the monitor connectivity and connectivity change 


messages support two levels of detail in this service: notification only of loss and discovery of 
connectivity, or notification of transitions between direct and indirect connectivity as well. 
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D.5.2.7 Station status protocol. 
The HF station status protocol (HSSP) shall be used to notify network members of changes in the 
operating mode of a station. HSSP messages shall be formatted as shown on figure D-12. 


source Addr Lp [Newstaus | Event time | Duration | checksum _| 


FIGURE D-12. Station status message format. 


a. The Source Addr field shall contain the address of the station sending the message, 
encoded in an address record (see D.5.2.5.1) with a source flag. 


b. The “D” bit shall be set to 1 if and only if the Duration field is present. 


c. The 7-bit New Status field shall report the new status of the reporting station as of the 
date and time indicated in the Event Time field, using the codes listed in table D-IX. 


TABLE D-IX. Station status codes. 


Normal operations 

Assumed net control (from non-net control stations) 
Relinquishing net control (from net control station) 
Radio silence 


Oo 


Reduced power 
Alternate scan set | 
Alternate scan set 2 
Alternate scan set 3 
Out of service 


NANAIDNABWN KE 


=a. 


d. The Event Time field (24 bits) shall contain the date and time that the new status will be 
effective for the station in accordance with figure D-13, except that an Event Time field 
containing all 1’s indicates that the new status is effective immediately after the message was 
sent. The Event Time shall be encoded in Zulu time (i.e., universal time, coordinated 
(UTC)), with the year digit holding the least-significant digit of the event year. 


Year Month Hour Minute 
(0 - 9) 


FIGURE D-13. Event time encoding. 


e. The optional Duration field (24 bits) shall be encoded in accordance with figure D-13 to 
indicate the expected duration of the status change. 


f. The 16-bit Checksum shall be computed in accordance with D.5.2.9. 
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NOTE: No length field is needed to determine the number of bytes contained in an HSSP 
message because the only variable-length field in the message is the Source address record, 
which contains an internal length field. 


D.5.2.8 Network broadcast address. 
Where permitted by network layer protocols, the broadcast address “@ ? @” (identical to ALE 
Allcall address) may be used to collectively refer to all reachable stations. 


D.5.2.9 Checksum computation. 

The 16-bit Checksum in network layer messages shall be computed as the 16-bit 1’s complement 
of the one’s complement sum of all relevant 16-bit words (either all words in the AME header or 
all words in the message for HRMP or HSSP). If the Checksum is to be computed over an odd 
number of bytes, the final byte shall be padded on the right with a 0-filled byte. For purposes of 
computing the checksum, the Checksum field itself shall be filled with 0 bits. 


D.5.2.10 Data transmission order. 

The order of transmission of the headers and data composing the messages described in this 
section (i.e., connectivity exchange, AME, relay management, and station status messages) is 
resolved to the octet or character level. 


The bytes of these messages shall be transferred in the order left-to-right then top-to-bottom, just 
as English words are read. In the case of multibyte fields, this means that the most significant 
(i.e., left-most) byte is transferred first. 


CONEX messages consist of 7-bit “characters” while messages from the other protocols consist 
of 8-bit bytes. In all cases, the bytes (or characters) of these messages shall be transferred in the 
order left-to-right then top-to-bottom, just as English words are read. In the case of 

multibyte (multicharacter) fields, this means that the most-significant (i.e., left-most byte 
(character) is transferred first. 


NOTE: The order of bit transmission within these units is determined by the data link 
protocol used and is transparent to network layer protocols. For example, ALE conveys data 
most significant bit first, while the HF Data Link Protocol (HFDLP) and most computer 
serial ports convey data least significant bit first. The HFDLP is contained in Appendix G. 
Although this data link protocol orders multibyte values within its own header least 
significant byte first, network layer messages are conveyed to data link protocols as 
individual bytes (i.e., multibyte fields appear only as a sequence of bytes to the data link 
protocol), and are carried on the data link in the order determined by the network layer 
entity. 


D.5.3 Network management. 

Programs that provide network management functionality are not standardized. Interoperation 
among such network management systems, however, requires the standardization of protocols for 
examining and changing the state of network elements, and of the abstract data objects 
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(management information) manipulated using the HNMP protocol. The protocol requirements 
are identified in D.5.3.2, and the management information requirements are defined in D.5.3.3. 


D.5.3.1 Terminology. 
Managed network elements (e.g., radios, ALE controllers, data modems, and networking 


controllers) are monitored and controlled by embedded network management agents (processes) 
which have access to the operating data of the elements and can initiate actions in those elements. 
Network management stations communicate with the agents to request the values of operating 
data, and to request that operating data be changed. Actions in management elements are 
produced as side effects when operating data are changed. For example, changing the antenna 
Mode value for a rotatable antenna causes the antenna to rotate (see Management Information 
Base (MIB), Appendix H, for the definition of antenna mode). 


D.5.3.2 Management protocol. 
SNMPv2, in accordance with RFC 1441 through 1452 shall be employed for HF network 
management, with the following additional requirements (see D.4.4.3). 


a. An agent receiving a SetRequest that selects a non-existent row in a table shall 
automatically create the requested row subject to resource availability, setting column objects 
in the new row to their default values unless other valid values are specified in the 
SetRequest message. However, if any value in the SetRequest message specifies an invalid 
value for any column object in the new row, the new row shall not be created, and a 
GetResponse message shall be returned indicating the erroneous variable binding. 


b. Table rows invalidated by a SetRequest shall not be reported in responses to 
GetNextRequests (i.¢e., from the point of view of management stations, invalidated rows are 
deleted from the table). 


c. Object identifiers for objects defined in the HF MIB (see Appendix H) may be encoded 
for transmission within HF networks only using the truncated encoding scheme of D.5.3.3.2. 
Gateways that connect HF networks to non-HF networks, however, shall ensure that object 
identifier encodings in messages entering non-HF networks use the full encoding of 
ISO/International Electrotechnical Commission (IEC) 8825; SNMP messages entering HF 
networks may be translated to use truncated encodings. 


d. Retransmission timeouts in network management programs shall be adjusted to allow 
time for link establishment, and for the transmission of requests and responses over modems 
that may be able to achieve throughputs of 100 b/s or less. 


D.5.3.2.1 Inside local HF station. 

The relationship of the network management protocol to the other protocols in use within an HF 
station is shown on figure D-14. HNMP requires only a connectionless datagram transport 
service (e.g., the UDP). Consequently, figure D-14 shows HNMP using UDP for a Transport- 
layer protocol, IP for an Internet-layer protocol, and the HF AME protocol (D.5.2.5) as the 
Network-layer protocol. IP datagrams sent through the HF AME protocol shall use port number 
5 in the network message header (AME header). Figure D-14 also shows integration of IEEE 
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802 protocols as an illustration of the use of HNMP over an Ethernet local area network. Other 
network protocols may be integrated similarly. 


D.5.3.2.2 Outside local HF station. 
When interoperation with management stations outside the local HF sub-network is not required, 


UDP and IP may be eliminated to reduce the overhead of network management messages. In this 
case, messages shall be directed to AME port number 6, which is a direct connection to HNMP. 


a 
Data Link ALE IEEE 802.2 
Appendix G 


Physical ALE MIL-STD-188-110 | IEEE 802.3 
Modem Modem (CSMA/CD) 
MIL-STD-188-141 Radio 


FIGURE D-14. Interrelationship of protocols. 


D.5.3.3 Management information. 
SNMP functions by reading and writing data structures defined for each item of controlled 


equipment. These data structures are defined using an abstract syntax so that the details of how 
the data are stored by individual network components are hidden. For example, aleScanRate (the 
rate at which an ALE controller scans channels as defined in the HF MIB, Appendix H) is simply 
defined to be an integer, with no indication of byte order, or even the number of bytes used to 
represent it on any particular ALE controller. 


a. Furthermore, some ALE controllers may store channel dwell time instead of scan rate, in 
which case a conversion from dwell time to or from scan rate is made whenever aleScanRate 
is read or written. This illustrates the fact that the objects manipulated by a network 
management station need not correspond directly to the internal data structures of managed 
elements. A principal function of agents in managed elements is the translation between the 
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abstract objects used in the management protocol and the actual data structures used in 
equipment. 


b. The objects that may be read and written using HNMP are defined in modules using 
Abstract Syntax Notation One (ASN.1), ISO/IEC 8824. RFC-1450 defines the objects 
commonly used to manage TCP/IP internets. The standard objects for HF network 
management are identified in the HF MIB, D.5.3.3.1. Objects specific to each 
manufacturer’s equipment are specified in a MIB provided by that manufacturer. A 
management station integrates MIB modules from the elements it manages, resulting in 
access to a wide-ranging and dynamic set of management data. The structure of MIBs is 
defined in RFC-1442. 


c. When data is exchanged over the air (or some other medium), all parties involved in the 
exchange shall use the same encodings for the data. The HNMP encoding rules are specified 
in D.5.3.3.2. 


D.5.3.3.1 HF Management information base (MIB). 

The HF MIB is contained in Appendix H. The MIB module contains groups of objects for radios 
(and related RF equipment), ALE controllers, linking protection, HF data modems (and 
associated data link controllers), and networking controllers. HF equipment complying with this 
paragraph shall implement the corresponding group of objects from the HF MIB, although access 
to these objects may be provided by proprietary protocols rather than HNMP (requiring proxy 
management, D.5.3.4). As a DO, new equipment should support HNMP directly. 


D.5.3.3.2 Encoding rules. 

Object names and values sent in HNMP messages shall be encoded in accordance with the Basic 
Encoding Rules for ASN.1, found in ISO/IEC 8825, with an optional truncated encoding for 
OBJECT IDENTIFIERs of objects from the HF MIB, as specified in the following text. Such 
truncated encodings shall not be used in messages outside HF networks. 


a. The object names used in variable bindings in HNMP messages are OBJECT 
IDENTIFIERs, which authoritatively identify each object named by specifying the location 
of its definition in a tree of standards. For objects defined in the HF MIB, the OBJECT 
IDENTIFIER may employ a truncated path that begins in the HF MIB, using the unique code 
123 (decimal) to indicate that the path to the definition begins in the HF MIB. For example, 
the ALE self address table may be identified as 123.2.16. 


b. For an object defined for general use (i.e., not HF-specified), HNMP messages shall carry 
the normal OBJECT IDENTIFIER for the object. For example, the sysDescr object shall be 
identified as 1.3.6.1.2.1.1.1 (which traces the following path: iso(1) org(3) dod(6) internet(1) 
mgmt(2) mib-2(1) sys(1) sysDescr(1)). 
D.5.3.4 Proxy management. 
When elements do not implement HNMP, they may still be managed by using proxy agents that 
translate the standard HNMP messages into proprietary messages understood by the non-HNMP 
(“foreign”) elements. 
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NOTE: As HNMP management of HF radio networks is phased in, few network elements 
will initially implement HNMP. Proxy agents will be needed to extend the management 
capability to current-generation equipment. As a general rule, the proxy agent for any 
foreign network element should reside in the lowest-level controller (see figure D-14) that 
has a control path to that element. 


a. In operation, HNMP traffic that is directed to a foreign element will be delivered to the 
proxy agent. The proxy agent shall translate the request into an appropriate message for the 
target element, in terms of the native control protocol for that element, and pass the 
translated message to the foreign element over any available control circuit. Responses 
received from the foreign agent shall be translated into HNMP messages and passed to the 
requesting management station. 


b. For efficiency purposes, proxy agents may cache frequently requested variables from 
foreign elements so that some traffic on the control paths within a station is eliminated. 


NOTE: Variable caching necessitates messages from the foreign element to the caching 
proxy agent to either update or invalidate cached copies when cached variables are changed 
by other than the proxy agent (e.g., from an element front panel). 


D.5.3.5 Access control. 
Access to the management information of network elements is controlled in HNMP at two levels. 


a. The first level is an administrative model that restricts the objects at each element that are 
accessible to other parties and the operations that may be performed by those parties. 


b. The second level of access control is authentication of messages, that is, determination 
that a message actually comes from the party named in the message. 


D.5.3.5.1 Administrative model. 

HNMP agents and management applications shall employ the administrative model of RFC- 
1445. Object identifiers for parties and contexts shall be assigned by network administrators, 
who shall in turn obtain space in the tree of object identifiers from the preparing activity of this 
standard. Transport domain identifiers specific to HF networks are defined in the HF MIB. 


D.5.3.5.2 Authentication. 

The following three authentication schemes should cover the range of requirements for HF 
networks. Management stations shall employ only the trivial authentication protocol in HNMP 
messages, unless the addressed party is known to support a more secure authentication protocol. 
All HNMP agents must therefore support the trivial authentication protocol, although the access 
permitted trivially-authenticated parties to management information may be restricted. 


NOTE: Since HNMP uses a broadcast medium, it is susceptible to injection of false 


messages by hostile forces. HF networks should strive for the highest possible level of 
authentication necessary for the mission to minimize this risk. 
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D.5.3.5.2.1 Trivial authentication. 

When trivial authentication is employed, an agent receiving an HNMP message shall compare 
the Transport-layer address of the originator of the message to a list of authentic Transport-layer 
addresses for the party sending the message. If a match is found, the agent shall assume the 
message is authentic. When Transport-layer addresses are not used, agents may either use lower- 
layer addresses for authentication, or simply assume that all messages are authentic, as 
determined by network management policy for each network. 


D.5.3.5.2.2 Personal identification number (PIN) authentication. 

An intermediate level of security may be achieved through the use of PIN authentication. When 
PIN authentication is employed, network management programs shall prompt the station operator 
to entera PIN. The network management program shall then insert this PIN as the authInfo in 
every SnmpAuthMssg that carries a request protocol data unit (PDU). Agents receiving these 
requests shall compare this PIN to a list of authentic PINs for the named party as in D.5.3.5.2.1 
above. 


Response and trap messages from agents shall carry the serial number of the responding device in 
place of a PIN. These serial numbers should be verified using a local table before assuming that 
a response or trap message is authentic. 


NOTE: This scheme can be easily spoofed by duplicating PINs and serial numbers 
intercepted from prior traffic. Because SetRequests may be more important to authenticate 
than responses and traps, the lists of valid PINs should be varied with time to heighten 
protection against bogus request messages. 


D.5.3.5.2.3 Cryptographic authentication. 

A secure authentication scheme for SNMP is specified in RFC-1446, section 3. This digest 
authentication protocol includes a digest of each authenticated message at the beginning of the 
message (authInfo in the SnmpAuthMsg). This digest is computed from the message contents 
and a secret initialization vector in such a way that it is considered computationally infeasible to 
“spoof” the authentication system. A time-of-day mechanism is included as well to limit the 
effects of replay attacks. 


When cryptographic authentication of HNMP traffic is required, the digest authentication 
protocol of RFC-1446 shall be employed, using the MD-5 Message Digest Algorithm of RFC- 
1321. Initialization vector distribution is beyond the scope of this standard. 


D.5.3.6 Traps. 

HNMP messages containing traps are sent by managed elements to management applications to 
announce exceptional events, such as equipment failures or degradation of operating parameters 
beyond programmed thresholds. Trap messages may be used to reduce the required rate of 
polling for most such events. 
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D.5.4 HFNC interface to local equipment (station data bus). 

The protocols specified in this section provides an optional interoperable mechanism to support 
the functionality specified in D.4.2.8.1 through D.4.2.8.3 for interconnecting an HFNC to one or 
more external link controllers (see figure D-15), as well as to other external equipment. 


NOTE: Use of this optional communication interface is dependent on the system 
configuration and performance requirements. This interface will not normally be used 
between devices interconnected by a high-speed “backplane” bus. 


The specific functions specified in D.4.2.8.1 and D.4.2.8.2 should be implemented using HNMP 
and the following objects from the HF MIB: 


a. Link control should use the aleConnectionTable for management of ALE links, and 
hfdlpLinkState and hfdlpOtherAddress for management of HFDLP links. 


b. Link quality reporting should use the aleLqaMatrix for link quality data. 


Access to these MIB objects in local equipment shall employ HNMP messages sent directly to 
those devices using the station data link protocol specified in D.5.4.2. These messages will not 
use the network-layer header, AME header, and optional IP and UDP headers that are needed for 
sending messages through the network. That is, these are not “network messages.” 


Network messages (messages sent to other stations) should use the station network message 
format specified in D.5.4.1. Network messages in this format are carried over the station data 
bus (D.5.4.3) within the data link frames of the Station Data Link Protocol (see D.5.4.2 and 
figure D-16). 


ALE 
Controller 


Data 


Modem 
Controller 


Data 
Modem 
Controller 


FIGURE D-15. Station data bus. 
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HNMP or Network Msg 


Flag Addr | Ctrl CRC (32 Flag 
Bits) 


FIGURE D-16. SDLP frame structure. 


D.5.4.1 Station network message format. 
The standard format for network messages passing between HFNCs and link controllers is shown 


on figure D-17. The first octet contains a count of the number of address octets in the link layer 
address of the distant station (destination of a message from HFNC to link controller, or source 
of a message from link controller to HFNC). This is followed by the indicated number of 
address octets, which is in turn followed by the network layer header and the remainder of the 
body of the network message. 


Address Length Link Layer Address Network Layer Message... 


Header 


FIGURE D-17. Station network message format. 


When a link controller receives a network message that specifies a destination to which it is not 
currently linked, a request to establish that link should be inferred. 


D.5.4.2 Station data link protocol. 

The point-to-point protocol (PPP) HDLC-like framing in accordance with RFC-1662 is 
recommended for use as a station data link protocol (SDLP) to carry traffic among devices in a 
station. In this scheme, HNMP and network messages are encapsulated within PPP packets, 
which are in turn carried in the Information field in HDLC frames (see figure D-16). 


Some modifications to this scheme are necessary for SDLP, as detailed below. Padding at the 
end of the PPP packet is neither necessary nor desirable, and shall not be inserted. 


NOTE: Padding can complicate the task of the receiving device. 


D.5.4.2.1 HDLC mode for SDLP. 

Links established by the HFNC shall operate in HDLC Normal Response Mode (NRM) in 
accordance with ISO/IEC 3309:1991, in which the HFNC acts as the “primary” device and polls 
the other “secondary” devices. The full range of HDLC frame types is used for SDLP, rather 
than solely Unnumbered Information frames as specified in RFC-1662. 
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Octet stuffing in accordance with RFC-1662 shall be used for transparency. This eliminates the 
need for bit stuffing (commonly required in other implementations of HDLC). 


NOTE: The underlying physical layer will normally be asynchronous (rather than octet or 
bit-synchronous). 


D.5.4.2.2 Bus arbitration. 

Devices within the station shall be assigned one-octet HDLC addresses (the LSB must be 1), 
with address 1 reserved for the HFNC. The address field in the HDLC frames shall always 
contain the address of the secondary device (not the HFNC). 


PPP links within a station shall be established only by the HFNC; other devices shall transmit 
frames on the station data bus only in response to “poll” frames from the HFNC (i.e., frames 
from the HFNC having the poll/final (P/F) bit in the HDLC Control field set to 1). 


D.5.4.2.3, PPP numbers. 

HNMP messages directed to local devices shall be sent using the network control PPP number 
assigned for HF (see Assigned Numbers RFC). Note that HNMP messages directed to remote 
devices will be embedded within network messages, following AME and possibly other headers. 


Network messages shall use the network-layer PPP number assigned for HF AME. 


D.5.4.2.4 PPP configuration options. 
The following options (at least) should be configured during SDLP link establishment: 


a. Cyclic Redundancy Check (CRC). Default is 16-bit CRC. SDLP implementations should 
negotiate use of 32-bit CRC in accordance with RFC-1570. 


b. Maximum Received Unit (MRU). Default is 1500 octets. SDLP implementations should 
negotiate an MRU appropriate to the station error environment. 


D.5.4.2.5 SDLP link establishment. 
The following sequence of frames shall be sent on the station data bus to establish a link from the 
HFNC to a link controller. 


a. The HFNC selects a link controller by sending a Set Normal response mode (SNRM) 
HDLC frame addressed to that link controller with the P/F bit set to 1. 


b. The link controller responds with an unnumbered acknowledge (UA) HDLC frame with 
the P/F bit set to 1. 


c. The HFNC attempts to open a PPP connection by sending an Information HDLC frame 
that contains a link control protocol (LCP) Configure-Request packet. This packet will 
specify the PPP configuration options (if any) that the HFNC wishes to change from their 
default values. 
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d. The link controller responds with an Information HDLC frame that carries its response to 
the Configure-Request (often a Configure-ACK). The HDLC frame from the HFNC is 
acknowledged in the HDLC header of the response. 


e. Additional PPP LCP packets may be exchanged to continue to negotiate, or to 
authenticate the link establishment. (The details of HDLC Normal Response Mode are 
implied and not repeated here.) 


The SDLP link is established when LCP Configure-Ack packets have been sent and received. 
Thereafter, HDLC Information frames are used to carry PPP packets carrying HNMP and 
network messages as described in D.5.4.3. 


NOTE: Because the HFNC must poll a link controller before the link controller may 
transmit, links may remain in existence between uses, and this link establishment procedure 
need not be executed before each message 1s transferred. 


D.5.4.3 Station physical layer. 
The physical layer protocol of the station data bus employs full duplex asynchronous 


transmission of 8-bit characters (octets) with no parity and one stop bit. The least significant bit 
of each octet shall be sent first. All devices should support a data rate of 9600 b/s; other data 
rates are optional (DO: automatically send and adapt to the data rate in use). 


The electrical interface shall be RS-485. The only circuits required are Transmitted Data 
(balanced), Received Data (balanced), Signal Ground, and Protective Ground. The HFNC shall 
drive the Transmitted Data circuit, and the other devices shall drive the Received Data circuit. 
D.5.4.4 Examples. 

Figure D-18 shows an example application of the station data bus concept in a large, unmanned 
(lights out) communication station. Because of electrical loading, more than a single station data 
bus would be required to connect the Message Switch/Node Controller to all of the assets shown. 
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FIGURE D-18. Station data bus example. 


Figure D-19 shows a conceptual “pop-up menu” oriented user interface for remotely controlling 
such a station. For each “level” of equipment, the operator selects devices by choosing from a 
menu of available devices of each type (e.g., crypto, modems, and radios), and links them 
together by clicking a mouse button between the rectangles shown. Each connection displayed is 
numbered with the index of the corresponding entry in the connection figure for the site (see HF 
MIB). 
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Security 


Level 2 


Mgmt 


FIGURE D-19. Menu-driven remote tech control. 


D.5.5 Multiple-media operation. 


HFNCs (level 2 or above) shall be capable of automatically routing voice and data traffic via any 
available data link(s). 


a. Level 2 HFNCs (with static routing tables) must be programmed to use specific media for 
each destination node. This may be accomplished by any combination of manual or remote 
programming (e.g., using HNMP). 


b. Level 3 and above HFNCs shall automatically evaluate links of any medium for adaptive 
routing using the Path Quality formulas (paragraphs D.5.2.1 and D.5.2.4.2). 


NOTE: The CONEX messages that carry the data necessary for path quality calculations 
will be less costly in terms of overhead on high-band-width alternate media than on HF 
links. In many applications, connectivity exchanges should be restricted to such high- 
bandwidth links, with query and notification-based protocols employed generally to discover 
and adapt to changing network topology and connectivity (see D.5.2.6.6.1 Routing Queries, 
D.5.2.6.6.3 Connectivity Monitoring, and D.5.2.7 Station Status Protocol). 


c. Level 4 HFNCs shall implement the IP and the Internet Control Message Protocol 
(ICMP), and shall be capable of routing traffic via any available subnet. 


D.6 NOTES. 
None. 
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APPLICATION PROTOCOLS FOR HF RADIO NETWORKS 


E.1 GENERAL. 


E.1.1 Scope. 
This appendix contains the requirements for the prescribed protocols and directions for the 


implementation and use of various communications applications in HF radio networks. 


E.1.2 Applicability. 
Applications provide advanced technical capabilities of automated HF radio. None of the 


features and functions described in this appendix are mandatory requirements for the user in the 
acquisition of an HF radio system. However, if the user requires the features and functions 
described herein, they shall be provided in accordance with the technical parameters specified in 
this appendix. 


E.2 APPLICABLE DOCUMENTS. 


E.2.1 General. 

The documents listed in this section are specified in sections E.3, E.4, and E.5 of this standard. 
This section does not include documents cited in other sections of this standard or recommended 
for additional information or as examples. While every effort has been made to ensure the 
completeness of this list, document users are cautioned that they must meet all specified 
requirements documents cited in sections E.3, E.4, and E.5 of this standard, whether or not they 
are listed. 


E.2.2 Government documents. 


E.2.2.1 Specifications, standards, and handbooks. 

The following specifications, standards, and handbooks form a part of this document to the 
extent specified herein. Unless otherwise specified, the issues of these documents are those 
listed in the issue of the Department of Defense Index of Specifications and Standards (DoDISS) 
and supplement thereto, cited in the solicitation. 


STANDARDS 
FEDERAL 
FED-STD-1037 Telecommunications: Glossary of 


Telecommunication Terms 


Unless otherwise indicated, copies of federal and military specifications, standards, and 
handbooks are available from the Naval Publications and Forms Center, ATTN: NPODS, 5801 
Tabor Avenue, Philadelphia, PA 19120-5099. 
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E.2.2.2 Other Government documents, drawings, and publications. 

The following other Government documents, drawings, and publications form a part of this 
document to the extent specified herein. Unless otherwise specified, the issues are those cited in 
the solicitation. 

None 


E.2.3, Non-Government publications. 

The following documents form a part of this document to the extent specified herein. Unless 
otherwise specified, the issues of the documents which are DoD adopted are those listed in the 
issues of the DODISS cited in the solicitation. Unless otherwise specified, the issues of the 
documents not listed in the DODISS are the issues of the documents cited in the solicitation (see 
6.3). 


INTERNET DOCUMENTS 

RFC-854 Telnet Protocol specification 

RFC-821 Simple Mail Transfer Protocol 

RFC-959 File Transfer Protocol 

RFC-1651 SMTP Service Extensions 

RFC-1730 Internet Message Access Protocol - Version 4 
RFC-1854 SMTP Service Extensions for Command Pipelining 
RFC-1939 Post Office Protocol - Version 3 

RFC-2068 Hypertext Transfer Protocol - HTTP/1.1 


(Internet documents may be obtained by anonymous file transfer protocol (ftp) from nis.nsf.net or 
nic.ddn.mil.) 


E.2.4 Order of precedence. 
In the event of a conflict between the text of this document and the references cited herein, the 


text of this document takes precedence. Nothing in this document, however, supersedes 
applicable laws and regulations unless a specific exemption has been obtained. 


E.3 DEFINITIONS. 


E.3.1 Standard definitions and acronyms. 
None. 


E.3.2 Abbreviations and acronyms. 
The abbreviations and acronyms used in this document are defined below. Those listed in the 
current edition of FED-STD-1037 have been included for the convenience of the reader. 
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ALE automatic link establishment 
ALM automatic link maintenance 
ARQ automatic repeat request 
COMSEC Communications Security 
e-mail electronic mail 
FTP file transfer protocol 
HF high frequency 
HMTP HF mail transport protocol 
HTTP hypertext transfer protocol 
IMAP4 Internet Mail Access Protocol - version 4 
IP Internet Protocol 
NSAP network service access point 
PDU protocol data unit 
POP3 Post Office Protocol - version 3 
SMTP simple mail transfer protocol 
TCP transmission control protocol 
UDP user datagram protocol 


E.4 GENERAL REQUIREMENTS 


E.4.1 Introduction. 

Figure E-1 illustrates the relationship of application-layer protocols to the protocols defined 
elsewhere in this standard. Interoperation among applications in use at different stations requires 
that the applications and all supporting protocols at the stations interoperate. Performance will 
then be determined by how well the protocol stacks work with each other and with the HF 
medium. 


HF - Native 
Applications 
Peer to peer communication 


Encryption (optional) 1 i 


HF Subnetwork Protocols 


2nd or 3rd Generation 


ALE, ALM, and ARQ 


and associated modem (s) 


HF Radio 


FIGURE E-1. HF application interoperation. 
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E.4.1.1 Required HF subnetwork protocols. 

To simplify the task of ensuring interoperability among applications using the HF medium, a 
small number of protocols is approved for use with the application protocols specified in this 
appendix. Systems that implement any application from this appendix shall use the following 
protocols to convey the corresponding application protocol data units (PDUs) over the HF 
medium: 


e HF subnetwork in accordance with Appendix D 


e ALE in accordance with Appendix A and ALM and ARQ in accordance with 
Appendix G (the second-generation suite), OR ALE, ALM, and ARQ in accordance with 
Appendix C (the third-generation suite) 


e HF radio in accordance with MIL-STD-188-141. 


E.4.1.2 Support for Internet applications. 

When an HF subnetwork is connected to other subnetworks using the Internet Protocol (IP) suite, 
Internet applications can use the resulting Internet as illustrated in figure E-2. For Internet 
applications, the third-generation link-layer suite (shown in figure E-2) will generally provide 
higher performance than the second-generation suite. 


Internet 
Applications 


I . < 
, Encryption (optional) 


Peer to peer communication 


IP (etc) IP (etc) 
ae ne LAN/WAN Subnetwork| =H F Subnetwork 
ae (if any) Layer (if any) Protocols 
LAN/WAN Link LAN/WAN Link 3rd Generation 

Layer ed — Layer ALE, ALM, ARQ 


LAN/WAN 
ae Layer 


LAN/WAN ‘ 
Physical Layer HF Radio 


Internet Host Internet-HF Gateway 


FIGURE E-2. Application interoperation via internet gateway. 


When a host computer is connected to the Internet via an HF network (e.g., HF Host in 

figure E-2), most Internet applications will call upon the Transmission Control Protocol (TCP) or 
the User Datagram Protocol (UDP) for end-to-end transport service to the distant Internet Host. 
These two protocols, in turn, require the services of IP for routing packets through the Internet. 
HF network designers should be aware of several potential performance problems that arise when 
TCP and IP are used in an HF network: 
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a. The two protocols together add 40 bytes of overhead to each application PDU sent. 


b. TCP connection setup requires an additional three-way handshake after the link 
establishment handshake and data link protocol startup. Each link turnaround consumes at 
least three interleaver times; when the MIL-STD-188-110 serial-tone modem is using its 4.8 
s interleaver, this three-way handshake will add at least 43 s to the time to establish a link (at 
least 58 s if the data rate is 75 bps). 


c. The TCP congestion avoidance mechanisms can significantly reduce throughput each 
time the HF data link throughput changes abruptly. 


For electronic mail (e-mail) transport through HF networks, an application-layer mail gateway 
can be employed at the boundary of the HF network that will eliminate the need for TCP within 
the HF network (see figure E-3). However, interactive applications (e.g., remote terminals, file 
transfer, and web browsing) will generally require the use of TCP. 


E-Mail 
Application 
(STMP) 


E-Mail E-Mail 
Gateway Application 
(HMTP*) (HTMP) 


! 
; Encryption (optional) 
I 


Peer to peer 
communication 


IP (etc) 


LAN/WAN Subnetwork LAN/WAN Subnetwork HE Subnetwork 
Layer (if any) Layer (if any) Protocols 


LAN/WAN Link LAN/WAN Link 3rd Generation 
Layer ALE, ALM, ARQ 


LAN/WAN 


Physical Layer Physical Layer HF Radio 


Internet Internet LANs and WANs Mail Gateway 
Host 


FIGURE E-3. Application-layer mail gateway. 


E.4.1.3 Security. 


Figures E-1, E-2, and E-3 show optional encryption of application data. If Communications 
Security (COMSEC) is implemented in this way, the control information conveyed to lower 
layers shall bypass encryption using an approved method. Link layer encryption may also be 
used. Further COMSEC considerations are beyond the scope of this appendix. 
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E.4.2 Electronic mail transfer. 

An HF e-mail system will be found to comply with this appendix if it conveys e-mail through HF 
networks using the required HF subnetwork protocols (see Required HF subnetwork protocols 
above) and the HF Mail Transfer Protocol (HMTP) described in E.5.2.1 (HF Mail Transfer 
Protocol). 


E.4.2.1 Mail transfer within HF networks. 

Mail shall be transferred within HF networks using HMTP, except as provided in the next 
paragraph. Wherever possible, application-layer mail gateways (see figure E-3) shall be 
employed to translate between SMTP and HMTP at the boundaries of the HF subnetwork, so that 
TCP is not used to convey mail over HF links. 


E.4.2.2 Mail retrieval by call-in users. 

When connectivity to a user is too infrequent to use HMTP to push messages to that user's host 
computer, a mail drop should be created at a host that can usually be reached by that user over a 
single HF link. One of the mail retrieval protocols from E.5.2.2 (HF mail retrieval protocols) 
shall be used to pull mail from the mail drop host to the user's host. 


E.4.3 Digital imagery transfer. (not yet standardized) 


E.4.4 Digital voice operation. (not yet standardized) 


E.4.5 Other applications. 
Interactive applications such as file transfer and hypertext transfer (in support of the worldwide 
web) shall employ the usual Internet application protocols for those applications: 


Application Protocol Reference 

Remote terminal telnet RFC-854 

File transfer File Transfer Protocol (FTP) RFC-959 

Hypertext transfer Hypertext Transfer Protocol RFC-2068 
(HTTP) 


TCP shall be implemented at the client and server hosts that support these applications. IP and 
related protocols shall be implemented at client and server hosts and at subnetwork gateways 
(often termed “routers”’) that interconnect HF subnetworks with other subnetworks (see 

figure E-2). Neither TCP nor IP is needed at other HF nodes. 
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E.5 DETAILED REQUIREMENTS. 


E.5.1 Introduction. 

The functions supported by the protocols specified in this section are optional. However, when 
the functionality provided by one of these protocols is required, that protocol shall be 
implemented as specified to provide that functionality. 


E.5.2 Electronic mail protocols. 
The HMTP shall be used to “push” e-mail messages through HF networks from one mail server 


to the next. The Post Office Protocol version 3 (POP3) or the Internet Mail Access Protocol 
version 4 (IMAP4) shall be used within HF networks to retrieve (“pull”) e-mail messages from 
servers. 


E.5.2.1 HF mail transfer protocol. 
The HF Mail Transfer Protocol (HMTP) is an extended version of the Simple Mail Transfer 


Protocol (SMTP). HMTP clients and servers shall implement SMTP in accordance with RFC 
821, the SMTP service extension (“EHLO”) protocol in accordance with RFC 1651, and 
command pipelining in accordance with RFC 1854. 


E.5.2.1.1 HMTP command grouping. 
When connected to a server that supports command pipelining, HMTP clients shall group 


commands to the maximum extent permitted in RFC 1854: 


a. All setup commands, including RSET (if required), MAIL, RCPT, and DATA, for each 
message shall be sent as a single group. 


b. Multiple messages sent to a single server shall be chained by appending the setup 
commands for each subsequent message to the message body of the preceding message. 


When connected to a server that does not support command pipelining, HMTP clients shall 
execute SMTP in its basic interlocked mode in accordance with RFC 821. 


E.5.2.1.2 HMTP over TCP. 
When HMTP uses TCP transport services, it shall listen on TCP port 25 (the well-known SMTP 
port), and, in general, use TCP in the same manner as does SMTP. 


E.5.2.1.3 HMTP without TCP. 
When TCP is not used to transport HMTP data, the HMTP server shall listen for calls on 
network service access point (NSAP) 8 of the HF subnetwork service. 


E.5.2.2_ HF mail retrieval protocols. 
When a user is usually not reachable (i.e., the user connects sporadically to pick up e-mail), 


HMTP will not be appropriate for delivery of mail fo that user. In such cases, POP3 in 
accordance with RFC 1939 or IMAP4 in accordance with RFC 1730 shall be used to retrieve 
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mail from a mail drop server (see E.4.2.2). Messages sent by such users shall be conveyed to the 
server using HMTP. 


E.5.3 Digital imagery protocol. 
(not yet standardized) 


E.5.4 Digital voice protocol. 
(not yet standardized) 


E.5.5 Radio facsimile protocol. 
(not yet standardized) 


E.6 NOTES. 


None. 
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ANTI-JAM AND ANTI-INTERFERENCE TECHNIQUES 
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F.1 GENERAL 


F.1.1 Scope. 
This appendix contains the requirements for implementation of third generation (3G) HF link 


automation when frequency hopping is used in anti-jam and anti-interference applications. 


F.1.2 Applicability. 
Frequency hopping operation with 3G HF link automation may not be required for some users of 


HF radio systems. However, if the user has a requirement for the features and functions 
described herein, they shall be implemented in accordance with the technical parameters 
specified in this appendix. 


F.2 APPLICABLE DOCUMENTS 


F.2.1 General. 

The documents listed in this section are specified in F.3, F.4 and F.5 of this appendix. This 
section does not include documents cited in other sections of this standard or recommended for 
additional information or as examples. While every effort has been made to ensure the 
completeness of this list, document users are cautioned that they must meet all specified 
requirements documents cited in F.3, F.4 and F.5 of this appendix, whether or not they are listed 
here. 


F.2.2 Government documents. 


F.2.2.1 Specifications, standards, and handbooks. 


The following specifications, standards, and handbooks form a part of this document to the 
extent specified herein. Unless otherwise specified, the issues of these documents are those 
listed in the issue of the Department of Defense Index of Specifications and Standards (DODISS) 
and supplement thereto, cited in the solicitation. 


STANDARDS 
FEDERAL 
FED-STD-1037 Telecommunications: Glossary of 
Telecommunications Terms 
MILITARY 


MIL-STD-188-148 | (S) Interoperability Standard for Anti-Jam (AJ) 
Communications in the High Frequency Band 2 
- 30 megahertz (MHz) (U) 


(Unless otherwise indicated, copies of the above specifications, standards, and handbooks are 
available from the Standardization Document Order Desk, 700 Robbins Ave. Building 4D, 
Philadelphia, PA 19111-5094.) 
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F.2.2.2 Other Government documents, drawings, and publications. 

The following other Government documents, drawings, and publications form a part of this 
document to the extent specified herein. Unless otherwise specified, the issues are those cited in 
the solicitation. 


NTIA Report 98-348 | Software Implementation of a Wideband HF Channel 
Transfer Function 


(Applications for copies should be addressed to the U.S. Department of Commerce, NTIA, Room 
4890, 14th and Constitution Ave. N.W., Washington, DC 20230.) 


F.3 DEFINITIONS 


F.3.1 Standard definitions and acronyms. 
None. 


F.3.2 Abbreviations and acronyms. 
The abbreviations and acronyms used in this document are defined below. Those listed in the 
current edition of FED-STD-1037 have been included for the convenience of the reader. 


a 3G third generation 

b AJ Anti-Jam 

c ALE Automatic Link Establishment 

d ALM Automatic Link Maintenance 

é AWGN additive white Gaussian noise 

f DODISS Department of Defense Index of 
Specifications and Standards 

g HF high frequency 

h kHz kiloHertz 

i MHz megahertz 

j PDU Protocol Data Unit 


F.3.3 Operating parameters. 
The operating parameters used in this appendix are collected here for the convenience of the 


reader. 


Symbol Parameter Name Default Value 
gi PSK symbol time 1/2400 s_ 417 us 
Tpit 32 Tsym; quantum of 3G PSK signaling ~13.333 ms 

Lone Maximum propagation delay among 70 ms 


network members 


Tings Duration of hopping dwell * 
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T guard Guard time at hop boundary for radio * 
tuning 

Tats Portion of hopping dwell used for data . 
transmission (Thop - Tguara) 

Tuisc Maximum discrepancy among * 
synchronized, hopping radios 

Tstot Duration of slot in synchronous mode 3G * 
ALE 

Noph Number of data bits sent per hop * 

Hpwo Number of hops necessary to send a 3G i 
ALE PDU while hopping 

C Number of calling hop sets scanned by 


radio that links while hopping 
* depends on specific hopping scheme in use 
F.4 GENERAL REQUIREMENTS 
F.4.1 Overview. 
Systems employing both 3G HF link automation (see Appendix C) and frequency hopping may 


operate in any of the following five modes listed in table F-I. 


TABLE F-I. Modes of operation. 


Hopping Mode Linking Mode Scanning Mode 
MIL-STD-188-148 Link before hopping Asyne 


MIL-STD-188-148 Link before hopping 


MIL-STD-188-148 Link while hopping 


F.4.2 Hop sets. 
An ordered list of frequencies, along with timing specifications that determine when each 


frequency is used, is termed a hop set. When 3G protocols are used in a frequency-hopping 
network, hop sets take the place of channels. Thus, in 3G systems that support frequency 
hopping, the channel table specified in C.4.11.3 Channel table shall be extended to store a hop 
set specification in each entry, and channel numbers in 3G automatic link establishment (ALE) 
and 3G automatic link maintenance (ALM) protocol data units (PDUs) shall refer to hop sets. 
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F.4.3 System performance requirements. 


F.4.3.1 Linking probability: link before hopping. 

When linking before hopping (Mode 1A, 1B, 3A, or 3B), 3G ALE systems shall meet or exceed 
the linking probability requirements of C.4.6.1.1 Linking probability and the appropriate sub- 
paragraph for linking in synchronous or asynchronous mode. 


F.4.3.2 Linking probability: link while hopping. 

When linking while hopping (Mode 2), 3G ALE systems shall meet or exceed the linking 
probability requirements of table F-II. The test procedure of A.4.2.3 shall be employed, with the 
following modifications: 


e The multipath delay settings shall be 0.5 ms for the Good channel and 2.0 ms for the Poor 
channel. (NOTE: testing is performed using a narrowband simulator because parameters 
have not yet been established for testing using the wideband model described in NTIA 
Report 98-348. Testing using a wideband channel simulator may be required in future 
revisions of this standard.) 


e Units under test shall hop in a single calling hop set (C = 1). 
e The requested traffic type shall be packet data. 


e A link will be declared successful if, in response to the first Call PDU sent, the 3G-ALE 
controllers complete an individual call handshake and both commence hopping on the 
traffic hop set specified in the Handshake PDU. 


e The time limit for each successful link shall be 6 seconds, measured from the time the 
request is presented at the operator interface until the start of the traffic setup PDU 
preamble. 


TABLE F-II. Linking probability requirements for linking while hoppin 


(3 kiloHertz (kHz) SNR dB). 


Prob Link Success CCIR Good CCIR Poor 
a E 3 


5 


F.4.3.3, Occupancy detection: link before hopping. 

When linking before hopping (Mode 1A, 1B, 3A, or 3B), 3G ALE systems shall meet or exceed 
the occupancy detection requirements of C.4.6.1.2 Occupancy detection and the appropriate sub- 
paragraph for synchronous or asynchronous operation. 


505 


MIL-STD-188-141B 
APPENDIX F 


F.4.3.3, Occupancy detection: link while hopping. 

3G ALE systems operating in link-while-hopping mode (Mode 2) shall correctly recognize that a 
traffic hop set is occupied at least as reliably as indicated in table C-II during the Listen portion 
of Slot 0 (see F.5.2.2, Hopping synchronous dwell structure). The test procedure of A.4.2.2 shall 
be used. Systems shall also meet or exceed the requirements of 

table F-III for detecting calling hop sets in use while listening before calling during Slots 1 
through 3. The probability of declaring a hop set occupied when each hop dwell contains only 
additive white Gaussian noise (AWGN) shall be less than 1 percent. 


TABLE F-III. Occupancy detection requirements for linking while hopping 
(3_ kHz SNR dB). 


aveform AWGN 3 kHz SNR (dB) Minimum Required Detection 
Probability 


50% 
IL-STD-188-110 or 30% 
FED-STD-1052 PSK 70% 


STANAG 4285 PSK 1 30% 
Imodem 


F.5 DETAILED REQUIREMENTS 


F.5.1 Linking before hopping. 
When 3G ALE systems link before hopping, the ALE protocols of Appendix C shall be 


employed with the following modification: hopping synchronization and startup shall occur at 
the point in the respective protocol at which traffic startup would occur in non-hopping 
operation. Traffic startup shall commence upon completion of hopping startup. 


F.5.2 Linking while hopping. 
When linking while hopping, a 3G ALE system shall operate in the modified synchronous mode 


specified below. The following timing parameters are used: 


e The hopping dwell period, denoted Thop, is the reciprocal of the hopping rate. 


e Each dwell comprises a guard time Tyuara, during which the radio is changing frequency, 
and a user data time Tgata, during which user data may be sent. Thop = Tguara + Taata- 


e Stations are synchronized while hopping. The maximum discrepancy among network 
member time bases 1s Tisc. 


e The maximum propagation delay among network member stations is Tprop. 


e The duration of the transmit level control, preamble, and data portions of the 3G-ALE 
PDU are Tic, Two pre, and Tpwo data, respectively 
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F.5.2.1 Hopping synchronous slot duration. 

When the network hopping rate is such that an entire 3G-ALE PDU can be sent during Taata, the 
slot time Tsiot Shall be equal to Thop. Otherwise, the 3G-ALE T-iot shall be extended to the 
smallest integral multiple of Thop greater than or equal to Tprop plus the time to send an entire 3G- 
ALE PDU using the procedure specified in F.5.2.3 Hopping PDU transmission. 


F.5.2.2 Hopping synchronous dwell structure. 
The dwell structure for 3G ALE while hopping shall comprise five slots, each of duration T stot: 


e Slot 0, during which stations shall synchronously check a traffic hop set for occupancy; 


e Slots 1-4, during which stations initiate calls and other protocols in accordance with 
Appendix C. 


F.5.2.3 Hopping PDU transmission. 
When any 3G PDU cannot be sent during a single hop, it shall be spread over multiple hops as 
described below. 


F.5.2.3.1 Hopping PDU transmit level control sequence. 

The transmit level control portion of a PDU shall be sent by the controller to the transmitter 
during Teuard and the first portion of Tgata, with symbols dropped from the beginning of the 
sequence if necessary so that the end of the Ty, sequence shall occur at time Tgis, after the end of 
the guard time (see figure F-1). Some of the symbols may be dropped by the transmitter while it 
is changing frequency. 


Segmet PDU data bits 


TLC Sequence Preamble 


—+|< 


Tdieg  ~S0.Ms Npph —* Thit 


FIGURE F-1. Hopping PDU transmission. 


F.5.2.3.2 Hopping 3G-ALE PDU transmission during data time. 
When Tyata > Tawo pre + Two data + 2 Taisc, the 3G-ALE PDU shall be sent during a single hop, 
with the preamble beginning immediately after the end of the Ty, sequence. 


Otherwise, the preamble and data portions of the 3G ALE PDU shall be split over multiple hops. 
The transmissions during each Thop shall be (a portion of) the Ty. sequence as described above, 
followed immediately by a 40 ms (96 symbol) segment of the preamble, followed immediately by 
up to Nppn PDU data bits: 
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N. = i - 40ms 2] 
bph T 
bit 


Transmissions should cease during the period from the final symbol of the PDU data bits until 
the first symbol of the next Ty, sequence. This will reduce interference levels. The number of 
hops required to send the 26 data bits that compose a 3G ALE PDU is Hgwo: 


Preamble segments shall be sent in order in successive hops, with the specified symbol sequence 
cycling back to the beginning if necessary in the later hops. If the unused PDU data bit positions 
in the final hop do not exceed Tprop, an extra hop must be included in Tsiot to allow for 
propagation to all network stations. 


F.5.2.3.3 Hopping transmission of other PDUs during data time. 
The other 3G PDUs shall be sent similarly to the 3G ALE PDUs. 


F.6 NOTES 
None. 


508 


MIL-STD-188-141B 
APPENDIX G 


APPENDIX G 


HF DATA LINK PROTOCOL 
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G.1 GENERAL 


G.1.1 Scope. 
The purpose of this appendix is to specify the requirements for an additional data link protocol to 
be used with implementations of second generation (2G) HF link automation. 


G.1.2 Applicability. 
2G HF link automation inherently includes data transfer protocols that use the frequency-shift 


keyed modem specified in Appendix A. The data link protocol specified in this appendix shall 
be used in 2G HF networks that employ data modems complying with MIL-STD-188-110. 


G.2, APPLICABLE DOCUMENTS 
G.2.1 General. 


This section does not include documents cited in other sections of this standard or recommended 
for additional information or as examples. 


G.2.2 Government documents. 

The following standard forms a part of this document to the extent specified herein. Unless 
otherwise specified, the issues of these documents are those listed in the issue of the Department 
of Defense Index of Specifications and Standards (DODISS) and supplement thereto cited in the 
solicitation. 


STANDARDS 
DEPARTMENT OF DEFENSE 


MIL-STD-188-110 Interoperability and Performance Standards for 
Data Modems 


(Unless otherwise indicated, copies of the above standard are available from the Standardization 
Document Order Desk, 700 Robbins Ave. Building 4D, Philadelphia, PA 19111-5094.) 


G.3 DEFINITIONS 
None. 


G.4 GENERAL REQUIREMENTS 
The data link protocol for 2G HF link automation is specified in MIL-STD-188-110. 


G.5 DETAILED REQUIREMENTS 
None. 


G.6 NOTES 


The earliest version of MIL-STD-188-110 that specifies a data link protocol is MIL-STD-188- 
110B. 
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H.1 GENERAL. 


H.1.1 Scope. 
The scope of this appendix is limited to the Management Information Base (MIB) for automatic 
high frequency (HF) radio networks. 


H.1.1.2 Applicability. 
This appendix defines the MIB for automated HF radio networks. Management of HF radio 


networks through the use of the Simple Network Management Protocol (SNMP) requires the 
formal definition of the data objects to be remotely read and written by a network management 
program. 


H.2. APPLICABLE DOCUMENTS. 


H.2.1 General. 

The documents listed in this section are specified in H.4 and H.5 of this standard. This section 
does not include documents cited in other sections of this standard or recommended for 
additional information or as examples. While every effort has been made to ensure the 
completeness of this list, document users are cautioned that they must meet all specified 
requirements documents cited in H.4, and H.5 of this standard, whether or not they are listed. 


H.2.2 Government documents. 


MIL-STD-187-721 Interoperability and Performance Standards for 
Advanced Adaptive HF Radio 


H.2.3 Non-Government publications. 

The following documents form a part of this document to the extent specified herein. Unless 
otherwise specified, the issues of the documents which are Department of Defense (DoD) 
adopted are those listed in the issues of the Department of Defense Index of Specifications and 
Standards (DODISS) cited in the solicitation. Unless otherwise specified, the issues of the 
documents not listed in the DODISS are the issues of the documents cited in the solicitation (see 
6.3). 
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INTERNET DOCUMENTS 


Structure and Identification of Management 
Information 


RFC-1157 A Simple Network Management Protocol (SNMP) 

RFC-1213 Management Information Base for Network 
Management of TCP/IP-based Internets: MIB-II 

RFC-1441 Introduction to Version 2 of the Internet-standard 
Network Management Framework 

RFC-1442 Structure of Management Information for Version 2 of 
the Simple Network Management Protocol (SNMPv2) 

RFC-1443 Textual Conventions for Version 2 of the Simple 
Network Management Protocol (SNMPv2) 

RFC-1444 Conformance Statements for Version 2 of the Simple 
Network Management Protocol (SNMPv2) 

RFC-1445 Administrative Model for Version 2 of the Simple 
Network Management Protocol (SNMPv2) 

RFC-1446 Security Protocols for Version 2 of the Simple Network 
Management Protocol (SNMPv2) 

RFC-1447 Party MIB for Version 2 of the Simple Network 
Management Protocol (SNMPv2) 

RFC-1448 Protocol Operations for Version 2 of the Simple 
Network Management Protocol (SNMPv2) 

RFC-1449 Transport Mappings for Version 2 of the Simple 
Network Management Protocol (SNMPv2) 

RFC-1450 Management Information Base for Version 2 of the 
Simple Network Management Protocol (SNMPv2) 

RFC-1451 Manager-to-Manager Management Information Base 

RFC-1452 Coexistence between Version | and Version 2 of the 


Internet-standard Network Management Framework 


May be obtained by anonymous ftp from nis.nsf.net or nic.ddn.mil. 


H.3 DEFINITIONS. 


H.3.1 Standard definitions. 
None. 


H.3.2 Abbreviations and acronyms. 
The abbreviations and acronyms used in this document are defined below. Those listed in the 


current edition of FED-STD-1037 have been included for the convenience of the reader. 
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ALE automatic link establishment 
AME automatic message exchange 
ARPANET Advanced Research Projects Agency Network 
ASN.1 abstract syntax notation | 
bps bits per second 
DoD Department of Defense 
HF high frequency 
HFDLP HF Data Link Protocol 
HNMP HF Network Management Protocol 
LP linking protection 
MIB Management Information Base 
PIN personal identification number 
PDU protocol data unit 
SNMP Simple Network Management Protocol 
SNMPv2 Version 2 of the Simple Network Management Protocol 
TCP/IP transmission control protocol/internet protocol 
UDP user datagram protocol 


H.4 GENERAL REQUIREMENTS. 


H.4.1 Introduction. 

Automation of HF radio networks to date has simplified the tasks related to establishing links 
using HF radios. However, the automatic link establishment (ALE) technology that hides the 
complexities of linking has generated a new problem in radio network management: the 
automatic controllers use a number of intricate data structures that must be kept consistent 
throughout a network if operations are to proceed smoothly. Some steps toward reducing the 
impact of this problem have been included in MIL-STD-187-721. 


H.4.1.1 Network Connectivity and equipment status. 
An aspect of network management that has not been addressed by the current HF standards is the 


need to observe network connectivity and equipment status from network control sites so that 
corrective action can be initiated promptly when malfunctions or other disruptions occur. 
Managers of packet networks have been at work on network management problems for some 
time, so it makes sense to look at the procedures used in these more mature automated networks 
to see whether they have technology that could be usefully applied to the management of HF 
networks. 


H.4.1.2 Internet suite of protocols. 
Perhaps the best-known of the packet network technologies is the Internet suite of protocols 


(including the transmission control protocol (TCP) / internet protocol (IP)), which grew out of 
the DoD-sponsored Advanced Research Projects Agency Network (ARPANET) research. The 
network management approach used in the Internet and associated sub-networks is based upon 
the Internet-standard Network Management Framework developed in the late 1980s. This 
technology is more often referred to by the protocol that it employs for managing network nodes, 
the SNMP [RFC-1157]. 
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H.4.2 SNMP. 

SNMP was designed so that it explicitly minimizes the number and complexity of management 
functions realized by the management agent itself. That is, the development costs of including 
SNMP in managed equipment are minimized at the expense of (perhaps) increasing the 
complexity of the software for network management stations. However, the ratio of managed 
nodes to management stations is large so the benefit of widespread implementation has greatly 
outweighed the cost of implementing the management software. 


To briefly summarize the salient points of the SNMP approach: 


a. Network management stations monitor and control network elements by communicating 
with agents in those elements. 


b. This interaction uses SNMP [RFC-1157] to get and set the values of defined data objects. 
Agents may also send trap messages to management stations to announce important events 
asynchronously. 


c. The defined data objects are described in the MIB [RFC-1213], which is currently 
strongly oriented toward the TCP/IP protocol suite, but is easily extensible. Object 
definitions are expressed formally in abstract syntax notation 1 (ASN.1) [ISO 8824]. 


d. Object names and values are encoded in accordance with a set of ASN.1 Basic Encoding 
Rules [ISO 8825]. 


e. When elements do not implement SNMP, they may still be managed by using proxy 
agents that translate the standard SNMP messages into proprietary messages understood by 
the non-SNMP elements. 


f. Authentication is included in the standard, although current practice uses only trivial 
authentication. The mechanism is extensible using ideas similar to HF linking protection. 


g. SNMP requires only a connectionless datagram transport service (e.g., the user datagram 
protocol (UDP) in the Internet, or a similar protocol on top of HF automatic message 
exchange (AME) in MIL-STD-187-721). 


h. SNMPv2, in accordance with RFC 1441-1452 shall be employed for HF network 
management with the following additional requirements: 


(1) An agent receiving a SetRequest that selects a non-existent row in a table shall 
automatically create the requested row subject to resource availability, setting column 
objects in the new row to their default values unless other valid values are specified in 
the SetRequest message. However, if any value in the SetRequest message specifies an 
invalid value for any column object in the new row, the new row shall not be created, and 
a GetResponse message shall be returned indicating the erroneous variable binding. 


(2) Table rows invalidated by a SetRequest shall not be reported in responses to 
GetNextRequests; that is, from the point of view of management stations, invalidated 
rows are deleted from the table. 
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(3) Object identifiers for objects defined in the MIB may be encoded for transmission within 
HF networks only using the truncated encoding scheme. Gateways that connect HF 
networks to non-HF networks, however, shall ensure that object identifier encodings in 
messages entering non-HF networks use the full encoding of ISO/IEC 8825; SNMP 
messages entering HF networks may be translated to use truncated encodings. 


(4) Retransmission timeouts in network management programs shall be adjusted to allow 
time for link establishment and for the transmission of requests and responses over 
modems that may be able to achieve throughputs of 100 bits per second (bps) or less. 


H.5 DETAILED REQUIREMENTS. 


H.5.1 SNMP function. 

SNMP functions by reading and writing data structures defined for each item of controlled 
equipment. These data structures are defined using an abstract syntax (ASN.1) so that the details 
of how the data are stored by individual network components are hidden. 


For example, aleScanRate (the rate at which an ALE controller scans channels) is simply defined 
to be an integer, with no indication of byte order, or even the number of bytes used to represent it 
on any particular ALE controller. Furthermore, some ALE controllers may store channel dwell 
time instead of scan rate, in which case a conversion from dwell time to or from scan rate is 
made whenever aleScanRate is read or written. 


H.5.1.1 Encoding rules. 
When data are exchanged over the air (or some other medium), it is necessary that all parties to 
the exchange use the same encodings for the data. 


The ASN.1 encoding rules [[SO 8825] name each object by tracing a path through a tree of 
standards to finally reach the leaf that defines that object. It seems reasonable, while within an 
HF network, to truncate this path to that portion that lies within the HF MIB, and use a special 
flag (1.e., the octet 123) to denote this. This is expected to reduce, by 4, the number of bytes 
needed to name each object, without compromising the interoperability of the proposed HF radio 
networks implementation of SNMP, described in this appendix. 


H.5.1.2 HNMP. 

SNMP version 2 (SNMPv2) modified for use in HF networks is called the HF Network 
Management Protocol (HNMP). The variations on SNMPv2 introduced for HF use are intended 
to reduce the amount of overhead bandwidth consumed by the network management protocol. 
These variations are as follows: 


a. Object identifiers for objects defined in the HF MIB shall be encoded for transmission 
using the truncated encoding scheme described above. 


b. A GetRows variant of the GetBulk message is used for efficient retrieval of rows of 
tables. 


c. A personal identification number (PIN) authentication is available. MD5 authentication is 
optional. 
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The GetRows operation is similar to the SNMPv2 GetBulk operation, except that the response to 
a GetRows is a new protocol data unit (PDU) format. A GetRows response includes the object 
Identify only of the first object in each row, followed by the values of all objects requested in that 
row. 


H.5.2 HNMP Performance. 

The performance of HNMP may be gauged by how many bits are transferred to perform common 
operations. A fairly complex station such as that shown schematically in figure 1, is used for 
computing some example bit counts. In this case, the station is postulated to contain one ALE 
controller, seven radios, 10 antennas, six HF Data Link Protocol (HFDLP) controllers, one 
antenna matrix, and one BLACK patch panel. A complete over-the-air load of ALE operating 
data using HNMP will transfer the following objects: 


e 14scalar values 

e Six Self Address Table entries 

e §=14 individual and threenet entries in the Other Address Table 
e 30 entries in the Channel Table 

e Three entries in the Channel Set Table 
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FIGURE H-1. Station data bus example. 
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Using HNMP, this transfer will require 2,831 octets. Using this as a baseline, the number of 
octets to load the remaining equipment is estimated on the following table: 


TABLE H-I. Over the air transfers. 


15,000 
HFDLP 


BLACK patch 


Total 20,000 
(est) 


H.5.3 Network management MIBs and HNMP definitions. 


Table H-2 contains MIBs for network management of automated HF radio networks. This MIB 
is merely a subset of the management information that will be needed for a full implementation 
of automated HF radio network management. Additional objects may be defined in equipment- 
specific MIBs as described in the structure of Management Information [RFC-1442]. 
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TABLE H-II. HF management information base. 
(ABSTRACT SYNTAX NOTATION (HF-MIB DEFINITIONS) 


HF-MIB DEFINITIONS ::= BEGIN 


IMPORTS 
experimental, OBJECT-TYPE, MODULE-IDENTITY, Counter32, Gauge32, 
TimeTicks 
FROM SNMPv2-SMI-- RFC 1442 


DisplayString, RowStatus, TimeStamp, TruthValue 
FROM SNMPv2-TC; -- RFC 1443 


hf MODULE-IDENTITY 
LAST-UPDATED "9408310212Z" 
ORGANIZATION "U.S. Army Information Systems Engineering Command" 
CONTACT INFO 
E Eric E. Johnson 


Postal: New Mexico State University 
Dept 3-O, (Electrical Computer Engineering) 
Las Cruces, NM 88003-0001 
USA 


Tel: +1505 646 4739 
Fax: +1505 646 1435 


E-mail: ejohnson@nmsu.edu" 


DESCRIPTION "The MIB module for MIL/FED-STD automated HF radio networks" 
::= {2 43 } -- (encoded as the single octet 123) 


admin OBJECT IDENTIFIER ::= { hf 1 } -- subtree for party context IDs... 
security OBJECT IDENTIFIER ::= { hf 2 } -- subtree for security features, 

-- including ECCM and multi-level security 
enterprises OBJECT IDENTIFIER ::= { hf 3 } -- subtree for enterprise-specific MIBs 
hfSystem OBJECT IDENTIFIER ::= { hf 4 } -- generally applicable objects 
patch OBJECT IDENTIFIER ::= { hf 5 } -- interconnection systems such as 

-- antenna matrices and patch panels 
antenna OBJECT IDENTIFIER ::= { hf 6 } -- antennas, couplers, etc. 
radio OBJECT IDENTIFIER ::= { hf 7 } -- radios 
ale OBJECT IDENTIFIER ::= { hf 8 } -- automatic link establishment controllers 
Ip OBJECT IDENTIFIER ::= { hf 9 } -- linking protection 
modem OBJECT IDENTIFIER ::= { hf 10 } -- modems 
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hfdlp OBJECT IDENTIFIER ::= { hf 11 } -- HF data link protocol 

ame OBJECT IDENTIFIER ::= { hf 12 } -- automatic message exchange 

hrmp OBJECT IDENTIFIER ::= { hf 13 } -- relay management protocol 
hsspOBJECT IDENTIFIER ::= { hf 14 } -- station status protocol 

hftp OBJECT IDENTIFIER ::= { hf 15 } -- HF transport protocol 

hnmp OBJECT IDENTIFIER ::= { hf 16 } -- HF network management protocol 
-- the HF system group 


hfControlMode OBJECT-TYPE 
SYNTAX INTEGER { 
other (1) 
local (2), -- device is under local control 
remote (3) -- remote control enabled 
} 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"locus of control" 
::= {hfSystem 1 } 


hfSelfTestMode OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"0 indicates device not performing self test; other values correspond to particular self 
tests; these values and their meanings vary from device to device" 
::= { hfSystem 2 } 


hfLastTestResult OBJECT-TYPE 

SYNTAX INTEGER 

MAX-ACCESS read-write 

STATUS current 

DESCRIPTION 

"0 indicates self test completed successfully; -1 indicates that no self test has been 

performed; positive values indicate failures with device-specific meanings; 
negative values are reserved for standardized fault codes." 

::= { hfSystem 3 } 


hfLastFault OBJECT-TYPE 
SYNTAX INTEGER (0..65535) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"last fault code returned by device; 0 for no fault" 
::= {hfSystem 4 } 
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hfLastMessage OBJECT-TYPE 
SYNTAX DisplayString 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"last diagnostic message returned by device; O-length string if none" 
= {hfSystem 5 } 


hfNoChange OBJECT-TYPE 
SYNTAX TruthValue 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"True if no change has occurred to hfLastTestResult, hgLastFault and hfLastMessage 
since each was last read. False if any has changed." 
::= { hfSystem 6 } 


hfNativeControlPort OBJECT-TYPE 

SYNTAX OCTET STRING (SIZE (1..65535)) 

MAX-ACCESS read-write 

STATUS current 

DESCRIPTION 

"This object implements a transparent pass-through to built-in proprietary control 

interfaces. Strings written to this object are effectively injected into the local 
control port of the device. Reading this object returns the status message(s), 
in order, returned by the device in response to the latest write to this object. 
All are in the native format of the device." 

::= {hfSystem 7 } 


-- the Device Ports and Ranks Tables 
-- The ports described in these tables are strictly physical. 
-- For "logical ports" use the interfaces group in MIB-II 


hfPortRanksTable OBJECT-TYPE 

SYNTAX SEQUENCE OF HfRankEntry 

MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 

"Table describing the groups, or ranks, of ports on a device. A rank may either be a 

logical rank of ports (as in a patch panel), or a group of similar ports (such 
as the audio inputs on a radio)." 

::= { hfSystem 8 } 


hfRankEntry OBJECT-TYPE 
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SYNTAX HfRankEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"an entry in the device port ranks table describing one rank of ports" 
INDEX { hfRankIndex } 
::= { hfPortRanksTable 1 } 


HfRankEntry ::= 
SEQUENCE { 
hfRankIndex 
INTEGER, 
hfRankType 
INTEGER, 
hfRankDescr 
DisplayString 
} 
hfRankIndex OBJECT-TYPE 
SYNTAX INTEGER 


MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"rank number; auxiliary variable used to identify one rank of ports in the device port 
ranks table" 
::= { hfRankEntry 1 } 


hfRankType OBJECT-TYPE 
SYNTAX INTEGER { 


other (1), -- none of the following 

unused (2), -- an unused rank 

binRed (3), -- binary ports for classified data 
binBlk (4), -- binary ports for unclassified data 
vfRed (5), -- analog ports for classified signals 
vfBlack (6), -- analog ports for unclas signals 

rfLow (7), -- radio-frequency ports (up to 300 W) 
rfHigh (8), -- radio-frequency ports (over 300 W) 


} 
MAX-ACCESS read-only 


STATUS current 
DESCRIPTION 

"type of ports in rank" 
::= { hfRankEntry 2 } 


hfRankDescr OBJECT-TYPE 
SYNTAX DisplayString 
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MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"description of rank of ports; for display to user' 
::= { hfRankEntry 3 } 


hfPortsTable OBJECT-TYPE 
SYNTAX SEQUENCE OF HfPortEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"table of ports in a rank" 
::= { hfSystem 9 } 
hfPortEntry OBJECT-TYPE 
SYNTAX HfPortEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"an entry in the ports table describing one port" 
INDEX { hfPortRankIndex hfPortIndex } 
::= {hfPortsTable 1 } 


HfPortEntry ::= 
SEQUENCE { 
hfPortRankIndex 
INTEGER, 
hfPortIndex 
INTEGER, 
hfPortStatus 
INTEGER, 
hfPortDescr 
DisplayString 
} 


hfPortRankIndex OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"rank number; auxiliary variable used to identify rank number of an entry in the 
Ports Table; corresponds to the rank number in the hfPortRanksTable" 
::= { hfPortEntry 1 } 


hfPortIndex OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS not-accessible 
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STATUS current 
DESCRIPTION 
"port number; auxiliary variable used to identify an entry in the Ports Table in which 
port in the rank)" 
::= { hfPortEntry 2 } 


hfPortStatus OBJECT-TYPE 
SYNTAX INTEGER { 


down (1), -- inoperative 
avail (2), -- available for normal operation 
inUse (3), -- in use for normal operation 
test (4), -- in some test mode; not available for use 
} 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"current operational status of port" 
::= { hfPortEntry 3 } 
hfPortDescr OBJECT-TYPE 
SYNTAX DisplayString 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"name of equipment or circuit attached to this port; for display to user" 
::= { hfPortEntry 4 } 


-- the Channel Table 
-- for any equipment that uses channel numbers to refer to operating frequencies 
-- and modes, e.g., radios and ALE controllers 


hfChannelTable OBJECT-TYPE 
SYNTAX SEQUENCE OF HfChannelEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"table of channel characteristics" 
::= {hfSystem 10 } 


hfChannelEntry OBJECT-TYPE 
SYNTAX HfChannelEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"an entry in the channel table" 
INDEX { hfChannelIndex } 
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::= { hfChannelTable 1 } 


HfChannelEntry ::= 
SEQUENCE { 
hfChannelIndex 
INTEGER, 
hfChannelType 
INTEGER, 
hfChannelRxFreq 
INTEGER, 
hfChannelRxMode 
HfModulation, 
hfChannelTxFreq 
INTEGER, 
hfChannelTxMode 
HfModulation, 
hfChannelAntenna 
INTEGER, 
hfChannelPower 
INTEGER, 
hfChannelStatus 
RowsStatus 
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hfChannelIndex OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"channel number; auxiliary variable used to identify an entry in the Channel Table" 
::= {hfChannelEntry 1 } 


hfChannelType OBJECT-TYPE 
SYNTAX INTEGER { 


other (1), -- none of the following 
unused (2), -- an unused channel 
duplex (3), -- a channel in duplex service (both directions simultaneously) 
simplex (4), -- a channel in simplex service (both directions, but one at 
a time) 
listen (5), -- a channel in receive-only service 
} 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 


"operating mode of channel" 
DEFVAL { simplex } 
::= {hfChannelEntry 2 } 


hfChannelRxFreq OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "Hz" 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
"frequency for this channel" 
DEFVAL {0} 
::= { hfChannelEntry 3 } 


hfChannelRxMode OBJECT-TYPE 
SYNTAX HfModulation 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
"receiving modulation for this channel" 
DEFVAL { usb } 
::= { hfChannelEntry 4 } 
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hfChannelTxFreq OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "Hz" 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
"transmitting frequency for this channel" 
DEFVAL {0} 
::= { hfChannelEntry 5 } 


hfChannelTxMode OBJECT-TYPE 
SYNTAX HfModulation 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
"transmitting modulation for this channel" 
DEFVAL { usb } 
::= { hfChannelEntry 6 } 


hfChannelAntenna OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
"antenna number (local significance: index into site antenna table)" 
DEFVAL {1} 
::= { hfChannelEntry 7 } 


hfChannelPower OBJECT-TYPE 

SYNTAX INTEGER { 

full (1), 

reduced (2) 
} 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"full or reduced transmitter power used on this channel?" 
DEFVAL {1} 
::= { hfChannelEntry 8 } 


hfChannelStatus OBJECT-TYPE 
SYNTAX RowStatus 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
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"The status column used for creating, modifying, and deleting Channel Table 
entries" 
DEFVAL { active } 
::= { hfChannelEntry 9 } 


HfModulation ::= 
INTEGER { 

cw (1), 
afsk (2), -- incl RATT 
am (3), -- incl AME 
usb (4), 
Isb (5), 
isb2 (6), 
isb4 (7), 
mcw (8), 
fm (9), 
fsk (10), 
psk (11) 


-- the Channel Set Table 


hfChannelSetTable OBJECT-TYPE 
SYNTAX SEQUENCE OF HfChannelSet 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"contains sets of channels for efficient reference to scan lists, etc." 
::= {hfSystem 11 } 


hfChannelSet OBJECT-TYPE 

SYNTAX HfChannelSet 

MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 

"an entry in the Channel Set Table" 

INDEX { hfChannelSetIndex } 

::= {hfChannelSetTable 1 } 


HfChannelSet ::= 
SEQUENCE { 
hfChannelSetIndex 
INTEGER, 
hfChannelSetMembers 
BIT STRING, 
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hfChannelSetStatus 
RowStatus 


} 


hfChannelSetIndex OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"auxiliary variable to identify an entry in Channel Set Table" 
::= { hfChannelSet 1 } 


hfChannelSetMembers OBJECT-TYPE 
SYNTAX BIT STRING 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
"Bit string that indicates which channels are in set. Bit number corresponds to 
channel number. A bit set to 1 indicates that the corresponding channel is in 
the set, while a bit set to 0 indicates that the corresponding bit is not in the 
set. The bit string need be no longer than the highest-numbered channel that 
is in the set plus one bit. (Bit 0 is always 0, unless equipment supports a 
channel numbered 0.)" 
::= { hfChannelSet 2 } 


hfChannelSetStatus OBJECT-TYPE 
SYNTAX RowStatus 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
"The status column used for creating, modifying, and deleting Channel Set Table 
entries" 
DEFVAL { active } 
::= { hfChannelSet 3 } 


-- the Patch group 
-- the Patch Connections Table 


patchConnectionsTable OBJECT-TYPE 
SYNTAX SEQUENCE OF PatchConnectionEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"table of connections among patch ports in automated patch panel" 
::= {patch 1 } 
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patchConnectionEntry OBJECT-TYPE 
SYNTAX PatchConnectionEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"an entry in the patch connections table" 
INDEX { patchRankA patchPortA patchRankB patchPortB } 
::= { patchConnectionsTable 1 } 


PatchConnectionEntry ::= 
SEQUENCE { 
patchRankA 
INTEGER, 
patchPortA 
INTEGER, 
patchRankB 
INTEGER, 
patchPortB 
INTEGER, 
patchConnectionStatus 
INTEGER 
} 
patchRankA OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 


"rank of first end of a patch connection; auxiliary variable used to identify an entry 
in Patch Connections Table" 
::= { patchConnectionEntry 1 } 


patchPortA OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"port of first end of a patch connection; auxiliary variable used to identify an entry 
in Patch Connections Table" 
::= { patchConnectionEntry 2 } 


patchRankB OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS not-accessible 
STATUS current 
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DESCRIPTION 
"rank of second end of a patch connection; auxiliary variable used to identify an 
entry in Patch Connections Table" 
::= { patchConnectionEntry 3 } 


patchPortB OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"port of second end of a patch connection; auxiliary variable used to identify an 
entry in Patch Connections Table" 
::= { patchConnectionEntry 4 } 


patchConnectionStatus OBJECT-TYPE 
SYNTAX INTEGER { 
free (1), -- written to release a connection, 
-- freeing the ports; 
-- read only in response to freeing SET 


seized (2), -- written to establish a connection; read when -- established 
reserved (3), -- written to capture ports without making the 
-- connection; 
-- read when both ports have been reserved 
} 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 


"current status of connection; an appropriate error code is returned when a 
connection cannot be established, reserved, or freed as requested, or in 
response to a get request for a non-existent connection" 

DEFVAL { seized } 
::= { patchConnectionEntry 5 } 


-- the antenna system group 
-- the antenna 


tableantennaTable OBJECT-TYPE 
SYNTAX SEQUENCE OF AntennaEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"Table of antennas under the control of the addressed device (antennas are not 
addressed directly)" 
::= {antenna 1 } 
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antennaEntry OBJECT-TYPE 
SYNTAX AntennaEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"An entry in the antenna table" 

INDEX { antennaIndex } 
::= { antennaTable 1 } 


AntennaEntry ::= 
SEQUENCE { 
antennaIndex 
INTEGER, 
antennaType 
INTEGER, 
antennaPolar 
INTEGER, 
antennaModel 
DisplayString, 
antennaMode 
INTEGER, 
antennaMaxPower 
INTEGER, 
antennaAzimuth, 
INTEGER 


} 


antennaIndex OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"Antenna number; auxiliary variable used to identify an entry in the Antenna 
Table" 
::= { antennaEntry 1 } 


antennaType OBJECT-TYPE 
SYNTAX INTEGER { 

other (1), -- none of the following 
whip (2), 
dipole (3), 
longwire (4), 
loop (5), 
omni (6), -- omnidirectional 
rlp (7), -- rotatable log-periodic 
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beam (8), -- any other multi-element assembly 
rhombic (9), 
slopingv (10), 
nvis (11) 
} 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"Type of antenna. When more than one of the types listed is applicable, use the 
most specific." 
::= { antennaEntry 2 } 


antennaPolar OBJECT-TYPE 
SYNTAX INTEGER { 
other (1), -- none of the following 
horizontal (2), 
vertical (3), 
circular (4) 
} 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"Polarization of antenna" 
::= { antennaEntry 3 } 


antennaModel OBJECT-TYPE 
SYNTAX DisplayString 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"Manufacturer and model of antenna" 
::= { antennaEntry 4 } 


antennaMode OBJECT-TYPE 
SYNTAX INTEGER { 


other (1), -- none of the following 
RxOnly (2), 
TxOnly (3), 
RxTx (4) 
} 
MAX-ACCESS read only 
STATUS current 
DESCRIPTION 


"Operating mode capability." 
::= { antennaEntry 5 } 
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antennaMaxPower OBJECT-TYPE 
SYNTAX INTEGER (-128..127) 
UNITS "dBW" 
MAX-ACCESS read only 
STATUS current 
DESCRIPTION 
"Maximum operating power of antenna. When rounding computed dBW to 
integer, round down." 
::= { antennaEntry 6 } 


antennaAzimuth OBJECT-TYPE 
SYNTAX INTEGER (0..359) 
UNITS "degrees" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"Current magnetic azimuth of antenna. Always 0 for omni antennas." 
::= { antennaEntry 7 } 


-- the radio group 


radioChannel OBJECT-TYPE 

SYNTAX INTEGER 

MAX-ACCESS read-write 

STATUS current 

DESCRIPTION 

"Index into Channel Table for the radio of its current operating channel. If its 

current frequencies and modes do not exactly correspond to an entry in that 
table, equal to -1." 

::= {radio 1 } 


radioKeyed OBJECT-TYPE 
SYNTAX TruthValue 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"1 if transmitter is keyed, 0 otherwise. Writing a 1 keys transmitter." 
::= {radio 2 } 


radioTxPower OBJECT-TYPE 
SYNTAX INTEGER (-128..127) 
UNITS "dBW" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
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"Nominal PA output power, as adjusted by power management commands. For 

example, a 100W radio returns 20 when operating at full rated power. 
Writing 10 to radioTxPower should cause this radio to reduce its power 
output by 10 dB to a nominal 1OW. Power adjustments will usually be 
approximations of the output power requested; the actual output power 
resulting from adjustment should be reported in the response to a set. (-128 
dBW indicates no power.)" 

::= {radio 3 } 


radioTxFreq OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "Hz" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"Current transmitting frequency." 
::= {radio 4 } 


radioTxMode OBJECT-TYPE 
SYNTAX HfModulation 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"Current transmitter modulation setting." 
= {radio 5} 


radioRxFreq OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "Hz" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"Current receiving frequency." 
::= {radio 6} 


radioRxMode OBJECT-TYPE 
SYNTAX HfModulation 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"Current receiver modulation setting." 
= {radio 7} 


radioTuned OBJECT-TYPE 
SYNTAX TruthValue 
MAX-ACCESS read-write 
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STATUS current 
DESCRIPTION 
"1 if radio and coupler tuned for radioTxFreq, 0 otherwise. Writing a 1 causes 
tuning (0 will be read until tuning is completed)." 
= {radio 8 } 


radioPABypass OBJECT-TYPE 
SYNTAX TruthValue 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"true for bypass; false for normal" 
= {radio 9} 


radioCouplerBypass OBJECT-TYPE 
SYNTAX TruthValue 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"true for bypass; false for normal" 
::= {radio 10} 


radioActiveAntenna OBJECT-TYPE 

SYNTAX INTEGER 

MAX-ACCESS read-write 

STATUS current 

DESCRIPTION 

"Index into antennaTable indicating the antenna currently in use (or ready for 
use)." 
= {radio 11} 


radioPreselectorBypass OBJECT-TYPE 
SYNTAX TruthValue 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"true for bypass; false for normal" 
::= {radio 12 } 


radioFrontEndAtten OBJECT-TYPE 
SYNTAX INTEGER (0..255) 
UNITS "dB" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"attenuation at front end" 
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::= {radio 13 } 


radioRFMute OBJECT-TYPE 
SYNTAX TruthValue 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"true if RF is muted, false if unmuted" 
= {radio 14} 


radioRFGain OBJECT-TYPE 
SYNTAX INTEGER (-128..127) 
UNITS "dB" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"gain of receiver RF amplifier relative to nominal" 
= {radio 15} 


radioVFO OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "Hz" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"frequency of VFO; 0 is off" 
= {radio 16} 


radioNoiseBlanker OBJECT-TYPE 

SYNTAX INTEGER (0..9) 

UNITS "arbitrary" 

MAX-ACCESS read-write 

STATUS current 

DESCRIPTION 

"noise blanker level; the range of levels supported by the radio shall be mapped 

into the range 0 through 9, with 9 being the highest level; 0 disables noise 
blanker" 

::= {radio 17} 


radioNotchFilterMode OBJECT-TYPE 
SYNTAX INTEGER { 
off (1), 
manual (2), 
automatic (3) 


} 
MAX-ACCESS read-write 
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STATUS current 
DESCRIPTION 
"operating mode of notch filter; in automatic mode, notch frequency tracks the 
interfering signal automatically" 
= {radio 18 } 


radioNotchFilterFrequency OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "Hz" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"center frequency of notch filter; read only when mode is automatic 
= {radio 19 } 


radioAGCMode OBJECT-TYPE 

SYNTAX INTEGER { 

off (1), 

fast (2), 

medium (3), 

slow (4), 

external (5), 

coherent (6), 

data (7) 
} 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"AGC speed and mode" 
::= { radio 20 } 


radioAudioClipEnable OBJECT-TYPE 
SYNTAX TruthValue 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"true if audio peak filter is on, false if off" 
= {radio 21 } 


radioAudioClipLevel OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "dB" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"level relative to nominal" 
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::= {radio 22 } 


radioAudioPassband OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "Hz" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"width of audio passband" 

= { radio 23 } 


radioPassbandTuning OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "Hz" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"variation of passband center frequency from nominal; 0 means passband tuning is 
off" 
= { radio 24 } 


radioBFO OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "Hz" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"frequency of beat frequency oscillator; 0 is off" 
::= { radio 25 } 


radioSquelch OBJECT-TYPE 
SYNTAX INTEGER (0..9) 
UNITS "arbitrary" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"squelch level; 0 is off" 

::= {radio 26 } 


radioSpeakerMute OBJECT-TYPE 
SYNTAX TruthValue 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"true if speaker is muted, false if unmuted" 
::= {radio 27 } 
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radioMicGain OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "dB" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"gain of microphone input" 

= { radio 28 } 


radioSpeechProcEnable OBJECT-TYPE 
SYNTAX TruthValue 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"true if speech processor is on, false if off" 
= {radio 29 } 


radioSpeechProcInputLevel OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "dB" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"level relative to nominal" 
::= { radio 30 } 


radioSpeechProcOutputLevel OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "dB" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"level relative to nominal" 
::= {radio 31 } 
radioAudioGain OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "dB" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"level relative to nominal" 
::= {radio 32 } 


radio VoxEnable OBJECT-TYPE 
SYNTAX TruthValue 
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MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"true if VOX is on, false if off" 
= { radio 33 } 


radioVoxGain OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "dB" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"gain relative to nominal" 

= { radio 34 } 


radioVoxAntiTrip OBJECT-TYPE 
SYNTAX INTEGER (0..9) 
UNITS "arbitrary" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"VOX circuit anti-trip setting" 
::= {radio 35 } 


radioVoxDelay OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "ms" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"VOX delay" 

::= { radio 36 } 


radioZeroize OBJECT-TYPE 
SYNTAX TruthValue 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"set to true to zeroize; reads as true if radio is zeroized" 
::= { radio 37 } 
radioScanSet OBJECT-TYPE 
SYNTAX SEQUENCE OF INTEGER 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"list of channel set indices in scan set" 
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= { radio 38 } 


radioScanRate OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "channels per second" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"rate at which receiver scans channels" 
= { radio 39 } 


radioStopScanThreshold OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "dB" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"level relative to nominal" 
::= {radio 40 } 


-- the radio gauges 


radioGauges OBJECT-TYPE 
SYNTAX SEQUENCE OF RadioGaugeEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"Table of read-only radio gauges. Organized in no particular order, each is 
identified by a name, and has integer-valued readings in specified units." 
::= {radio 41 } 


radioGaugeEntry OBJECT-TYPE 
SYNTAX RadioGaugeEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"An abstract radio gauge" 

INDEX { radioGaugeIndex } 
::= { radioGauges 1 } 
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RadioGaugeEntry ::= 
SEQUENCE { 
radioGaugelIndex 
INTEGER, 
radioGaugeName 
DisplayString, 
radioGaugeUnits 
DisplayString, 
radioGaugeReading 
Gauge, 
radioGaugeTrapHigh 
Gauge, 
radioGaugeTrapLow 
Gauge 
} 


radioGaugeIndex OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"gauge number; auxiliary variable used to identify an entry in the table of radio 
gauges" 
::= { radioGaugeEntry 1 } 


radioGaugeName OBJECT-TYPE 
SYNTAX DisplayString 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"Name of the quantity whose value is displayed on the gauge." 
::= { radioGaugeEntry 2 } 


radioGaugeUnits OBJECT-TYPE 
SYNTAX DisplayString 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"Units of the value displayed on the gauge. Should be selected so that integer 
readings are useful." 
::= { radioGaugeEntry 3 } 


radioGaugeReading OBJECT-TYPE 
SYNTAX Gauge 
UNITS "specified in radioGaugeUnits" 
MAX-ACCESS read-only 
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STATUS current 
DESCRIPTION 

"Most recent value of the quantity named in radioGaugeName' 
::= { radioGaugeEntry 4 } 


radioGaugeTrapHigh OBJECT-TYPE 

SYNTAX Gauge 

UNITS "specified in radioGaugeUnits" 

MAX-ACCESS read-write 

STATUS current 

DESCRIPTION 

"threshold above which a trap will be generated automatically" 

::= { radioGaugeEntry 5 } 


radioGaugeTrapLow OBJECT-TYPE 

SYNTAX Gauge 

UNITS "specified in radioGaugeUnits" 

MAX-ACCESS read-write 

STATUS current 

DESCRIPTION 

"threshold below which a trap will be generated automatically" 

::= { radioGaugeEntry 6 } 


-- the ALE group 


aleScanRate OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "channels per second" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"rate at which ALE receiver scans channels" 
= {alel} 


aleMaxScanChan OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"maximum number of channels scanned for network" 
= {ale2} 


aleMaxTuneTime OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "100 ms" 
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MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"maximum tune time for network" 
:= {ale3} 


aleTurnAroundTime OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "100 ms" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"maximum Tta for network" 

:= {ale 4} 


aleActivityTimeout OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "seconds" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"wait-for-activity timeout Twa" 
= {ale5} 


aleListenTime OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "seconds" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"listen before transmit time Twt" 
= {ale6} 


aleAcceptAnycall OBJECT-TYPE 
SYNTAX INTEGER { 
respond (1), 
ignore (2) 
} 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"will ALE controller respond to anycalls" 
= {ale7} 


aleAcceptAllcall OBJECT-TYPE 
SYNTAX INTEGER { 
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accept (1), 
ignore (2) 
} 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"will ALE controller detect and stop scan for allcalls " 
= {ale 8} 


aleAcceptAMD OBJECT-TYPE 
SYNTAX INTEGER { 
display (1), 
store (2), 
displayAndStore (3), 
ignore (4) -- doesn't require return to scan 
} 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"ALE controller action(s) upon receipt of AMD message" 
:= {ale9} 


aleAcceptDTM OBJECT-TYPE 
SYNTAX INTEGER { 
accept (1), 
ignore (2) 
} 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"ALE controller action upon receipt of data text message’ 
= {ale 10} 


aleAcceptDBM OBJECT-TYPE 
SYNTAX INTEGER { 
accept (1), 
ignore (2) 
} 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"ALE controller action upon receipt of data block message" 
= {ale 11} 


aleRequestLQA OBJECT-TYPE 
SYNTAX INTEGER { 
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always (1), -- request LQA in every ALE transmission 
callOnly (2), -- request LQA only in ALE call 
never (3) 
} 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"ALE protocol phases in which ALE controller will request an LQA report" 
:= {ale 12} 
aleAutoPowerAdj OBJECT-TYPE 
SYNTAX INTEGER { 
always (1), -- evaluate every received ALE transmission, but 
-- request power adjustment only when needed 
callOnly (2), -- negotiate power only during link 
-- establishment 
never (3) 
} 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 


"ALE protocol phases in which ALE controller will generate power adjust 
commands to distant station, based upon measurement of received signal 
strength" 

= {ale 13} 


AleAddress ::= OCTET STRING (SIZE (1..15)) 
-- one to fifteen characters from [A-Z, 0-9] 
-- the ALE Self Address Table 


aleSelfAddrTable OBJECT-TYPE 
SYNTAX SEQUENCE OF AleSelfAddrEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"table of 'self' addresses for ALE controller, along with ALE information relevant 
to each self address" 
REFERENCE "see MIL-STD-188-141" 
:= {ale 14} 


aleSelfAddrEntry OBJECT-TYPE 
SYNTAX AleSelfAddrEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"an entry in the ALE Self Address Table" 
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INDEX { IMPLIED aleSelfAddr } 
::= {aleSelfAddrTable 1 } 


AleSelfAddrEntry ::= 
SEQUENCE { 
aleSelfAddr 
AleAddress, 
aleSelfAddrStatus 
INTEGER, 
aleNetAddr 
AleAddress, 
aleSlotWaitTime 
INTEGER, 
aleSelfAddrValidChannels 
INTEGER 


} 


aleSelfAddr OBJECT-TYPE 
SYNTAX AleAddress 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"ALE self address; one to fifteen characters from [A-Z, 0-9]; auxiliary variable 
that uniquely identifies one entry in the ALE Self Address Table" 
::= {aleSelfAddrEntry 1 } 


aleSelfAddrStatus OBJECT-TYPE 

SYNTAX RowStatus 

MAX-ACCESS read-create 

STATUS current 

DESCRIPTION 

"The status column used for creating, modifying, and deleting ALE self address 
table entries" 
DEFVAL { active } 
::= {aleSelfAddrEntry 2 } 


aleNetAddr OBJECT-TYPE 

SYNTAX AleAddress 

MAX-ACCESS read-create 

STATUS current 

DESCRIPTION 

"ALE address of net to which this self address belongs" 

DEFVAL {""} 

::= {aleSelfAddrEntry 3 } 


aleSlotWaitTime OBJECT-TYPE 
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SYNTAX INTEGER 
UNITS "ALE word time Tw (130.667 ms)" 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"slot wait time for responding to net call" 
::= {aleSelfAddrEntry 4 } 


aleSelfAddrValidChannels OBJECT-TYPE 


SYNTAX INTEGER 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
"index into channel set table (0 means all channels valid)" 
DEFVAL {0} 
::= {aleSelfAddrEntry 5 } 


-- the ALE Other Address Table 


aleOtherAddrTable OBJECT-TYPE 


SYNTAX SEQUENCE OF AleOtherAddrEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"ALE addresses of other stations and nets known to this ALE controller' 
REFERENCE "see MIL-STD-188-141" 
:= {ale 15} 


aleOtherAddrEntry OBJECT-TYPE 


SYNTAX AleOtherAddrEntry 

MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 
"an entry in the ALE Other Address Table" 
INDEX { IMPLIED aleOtherAddr } 

::= { aleOtherAddrTable 1 } 


AleOtherAddrEntry ::= 


SEQUENCE { 
aleOtherAddr 
AleAddress, 
aleOtherAddrStatus 
INTEGER, 
aleOtherAddrNetMembers 
OCTET STRING, 
aleOtherAddrValidChannels 
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INTEGER, 
aleOtherAddrAnt 
INTEGER, 
aleOtherAddrAntAzimuth 
INTEGER, 
aleOtherAddrPower 
INTEGER 
} 
aleOtherAddr OBJECT-TYPE 
SYNTAX AleAddress 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 


"ALE address; one to fifteen characters from [A-Z, 0-9]; auxiliary variable that 
uniquely identifies one entry in the ALE Other Address Table" 
::= { aleOtherAddrEntry 1 } 
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aleOtherAddrStatus OBJECT-TYPE 
SYNTAX RowStatus 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
"The status column used for creating, modifying, and deleting ALE Other Address 
Table entries" 
DEFVAL { active } 
::= { aleOtherAddrEntry 2 } 


aleOtherAddrNetMembers OBJECT-TYPE 
SYNTAX SEQUENCE OF AleAddress 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
"List of ALE addresses of net members, in slot order. Empty list if this other 
address is not a net address. Unknown net member addresses set to '@' " 
DEFVAL { } -- empty sequence 
::= { aleOtherAddrEntry 3 } 


aleOtherAddrValidChannels OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
"index into channel set table (0 means all channels valid)" 
DEFVAL {0} 
::= { aleOtherAddrEntry 4 } 


aleOtherAddrAnt OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
"Antenna number (antennaIndex) to use in links with this station or net. 0 means 
default to antenna specified for channel in hfChannelTable" 
DEFVAL {0} 
::= { aleOtherAddrEntry 5 } 


aleOtherAddrAntAzimuth OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
"Azimuth of rotatable antenna to use in links with this station or net. 0 is default." 
DEFVAL {0} 
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::= { aleOtherAddrEntry 6 } 


aleOtherAddrPower OBJECT-TYPE 
SYNTAX INTEGER { 
default (0), 
full (1), 
reduced (2) 
} 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
"Power to use in links with this station or net. 0 means default to power specified 
for channel in hfChannelTable" 
DEFVAL {0} 
::= { aleOtherAddrEntry 7 } 


-- the LQA matrix 


aleLqaMatrix OBJECT-TYPE 
SYNTAX SEQUENCE OF AleLqaEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"table of link quality measurements" 
:= {ale 16} 


aleLqaEntry OBJECT-TYPE 
SYNTAX AleLqaEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"an entry in the ALE Other Address Table" 
INDEX { IMPLIED aleLqaAddr aleLqaChannel } 
::= { aleLqaMatrix 1 } 


AleLgaEntry ::= 
SEQUENCE { 
aleLqaAddr 
AleAddress, 
aleLqaChannel 
INTEGER, 
aleLqaStatus 
INTEGER, 
aleLqaAge 
INTEGER, 


22 


MIL-STD-188-141B 
APPENDIX H 


aleLqaMultipath 
INTEGER, 
aleLqaSINAD 
INTEGER, 
aleLqaBER 
INTEGER 
} 
aleLqaAddr OBJECT-TYPE 
SYNTAX AleAddress 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"ALE address; one to fifteen characters from [A-Z, 0-9]; auxiliary variable that 
identifies (along with channel number) one entry in the ALE LQA Matrix" 
::= {aleLqaEntry 1 } 


aleLqaChannel OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"Channel number of LQA measurement; auxiliary variable that identifies (along 
with aleLqaAddr) one entry in the ALE LQA Matrix" 
::= {aleLqaEntry 2 } 


aleLqaStatus OBJECT-TYPE 
SYNTAX RowStatus 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
"The status column used for creating, modifying, and deleting LQA Matrix 
entries" 
DEFVAL { active } 
::= { aleLqaEntry 3 } 


aleLqaAge OBJECT-TYPE 
SYNTAX INTEGER { 


IqaFifteen (0), -- 0-15 minutes 
IqaThirty (1), -- 15-30 minutes 
IqaSixty (2), -- 30-60 minutes 
IqaTwoHr (3), —-- 1-2 hours 
IqaFourHr (4), —-- 2-4 hours 
IqaToday (5), -- 4-23 hours 


IqaYesterday (6), -- 23-25 hours 
IqaTooOld (7) — -- over 25 hours or unknown 
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MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 

"Age of LQA measurement" 
::= { aleLqaEntry 4 } 


aleLqaMultipath OBJECT-TYPE 
SYNTAX INTEGER (0..7) 
UNITS "ms" 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
"multipath measurement; 7 means unknown" 
::= { aleLqaEntry 5 } 


aleLqaSINAD OBJECT-TYPE 
SYNTAX INTEGER (0..31) 
UNITS "dB" 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
"SINAD measurement; 31 means unknown" 
::= { aleLqaEntry 6 } 


aleLqaBER OBJECT-TYPE 
SYNTAX INTEGER (0..31) 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
"pseudo-BER measurement; 31 means unknown" 
::= { aleLqaEntry 7 } 


-- the ALE controls 


aleScanSet OBJECT-TYPE 
SYNTAX SEQUENCE OF INTEGER 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"list of channel set indices in scan set" 
= {ale 16} 


aleConnectionTable OBJECT-TYPE 
SYNTAX SEQUENCE OF AleConnectionEntry 
MAX-ACCESS not-accessible 
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DESCRIPTION 
"table of currently-linked stations" 
:= {ale 17} 


aleConnectionEntry OBJECT-TYPE 

SYNTAX AleConnectionEntry 
MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 

"an entry in the ALE Connection Table" 

INDEX { IMPLIED aleConnectedAddr } 

::= {aleConnectionTable 1 } 


AleConnectionEntry ::= 
SEQUENCE { 
aleConnectedAddr 
AleAddress, 
aleConnectionStatus 
INTEGER 


} 


aleConnectedAddr OBJECT-TYPE 

SYNTAX AleAddress 

MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 

"ALE address of station or net to which connected; auxiliary variable that uniquely 
identifies one entry in the ALE Connection Table" 
::= { aleConnectionEntry 1 } 


aleConnectionStatus OBJECT-TYPE 

SYNTAX RowStatus 

MAX-ACCESS read-create 

STATUS current 

DESCRIPTION 

"The status column used for creating, modifying, and deleting ALE Connection 

Table entries. Management stations may initiate link establishment by 
setting aleConnectionStatus to createAndGo. During link establishment, the 
connection status will be notInService, changing to active when the link is 
established. Management stations may initiate link termination by setting 
aleConnectionStatus to destroy." 

DEFVAL { notInService } 

::= { aleConnectionEntry 2 } 


-- the LP (linking protection) group 
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IpLevelsAvail OBJECT-TYPE 
SYNTAX BIT STRING { 
unprotected (0), -- no linking protection 


all (1), -- unclassified application level AL-1 
al2 (2), -- unclassified enhanced application level AL-2 
al3 (3), -- unclassified but sensitive application level AL-3 
al4 (4), -- classified application level AL-4 
other (5) -- any AL not identified in MIL-STD-188-141 

} 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 


"Reports available linking protection (LP) application levels. Because AL-1 is the 
defined interoperability level, the all bit may be 0 only if all bits other than 
bit 0 are also set to 0, indicating no LP capability." 

REFERENCE "see MIL-STD-188-141, Linking protection application levels" 


= {Ip1} 
-- the modem group 


modemStatus OBJECT-TYPE 
SYNTAX INTEGER { 


other (1), -- none of the following 
available (2), -- "on hook" 
connecting (3), -- "off hook" but no received carrier 
carrier (4), -- "off hook" and receiving carrier 
dataSync (5), -- "off hook," receiving carrier, and 
-- achieved data synchronization 

fault (6) -- failure detected 

} 

MAX-ACCESS read-write 

STATUS current 

DESCRIPTION 


"modem status; only the following values are valid in a set operation: available (2) 
forces the modem on-hook or resets a fault, and connecting (3) initiates a 
(re)connection attempt" 
::= {hf modem 1 } 


modemMode OBJECT-TYPE 
SYNTAX INTEGER { 
other (1), -- none of the following 
hfSerialTone (2), 
hf16Tone (3), 
hf39Tone (4), 
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fsk170 (5), -- 170 Hz shift 
fsk850 (6), -- 850 Hz shift 
stanag4285 (7), 
be11103 (8), -- 300 bps 
be11212a (9), -- 1200 bps 
v21 (10), -- 300 bps 
v22 (11), -- 1200 bps 
v22bis (12), -- 2400 bps 
v32 (13), -- 4800/9600 bps 
v32bis (14) -- 7200/9600/12000/14400 bps 

MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 


"modem operating mode; a set operation that specifies an unavailable mode shall 
not change the operating mode" 
::= {hf modem 2 } 


modemA vailableModes OBJECT-TYPE 
SYNTAX BIT STRING { 
other (1), -- none of the following 
hfSerialTone (2), 
hf16Tone (3), 
hf39Tone (4), 


fsk170 (5), -- 170 Hz shift 
fsk850 (6), -- 850 Hz shift 
stanag4285 (7) 
be11103 (8), -- 300 bps 
be11212a (9), -- 1200 bps 
v21 (10), -- 300 bps 
v22 (11), -- 1200 bps 
v22bis (12), -- 2400 bps 
v32 (13), -- 4800/9600 bps 
v32bis (14) -- 7200/9600/12000/14400 bps 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"available operating modes" 
::= {hf modem 3 } 


modemMaxDataRate OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "bps" 
MAX-ACCESS read-only 
STATUS current 
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DESCRIPTION 
"maximum data rate supported by modem" 
::= {hf modem 4 } 


modemTxDataRate OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "bps" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"data rate for data sent by modem; set operation causes data rate change at next 
logical opportunity" 
::= {hf modem 5 } 


modemTxInterleaver OBJECT-TYPE 

SYNTAX INTEGER 

UNITS "100 ms" 

MAX-ACCESS read-write 

STATUS current 

DESCRIPTION 

"interleaver length used in sending data; 0 means no interleaver; a set operation 

that specifies an unavailable length should result in use of the nearest 
available length to that specified" 

::= {hf modem 6 } 


modemRxDataRate OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "bps" 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"rate of data currently (or most recently) received by modem" 
::= {hf modem 7 } 


modemRxInterleaver OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "100 ms" 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"interleaver length used for data currently (or most recently) received by modem' 
::= {hf modem 8 } 


modemRxSNR OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "dB" 
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MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"signal-to-noise ratio measured for data currently (or most recently) received by 
modem" 
::= {hf modem 9 } 


modemRxFreqOffset OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "Hz" 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"measured data carrier offset for data currently (or most recently) received by 
modem" 
::= {hf modem 10 } 


modemLoopbackMode OBJECT-TYPE 
SYNTAX INTEGER { 


none (1), -- no loopback 
digital (2), -- transmit data connected to receive data 
analog (3) -- transmit analog signal connected to 
-- receive analog input 
} 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 


"modem loopback mode; a set operation that specifies an unavailable mode shall 
effect no change" 
::= {hf modem 11 } 


modemDuplexMode OBJECT-TYPE 
SYNTAX INTEGER { 


other (1), -- none of the following 
simplex (2), -- send and receive alternately 
duplex (3), -- send and receive simultaneously 


-- ("full" duplex) 
sendOnly (4), 
rcvOnly (5) 
} 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"modem duplex mode; a set operation that specifies an unavailable mode shall 
effect no change" 
::= {hf modem 12 } 
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modemARQProtocol OBJECT-TYPE 
SYNTAX INTEGER { 
none (1), -- no ARQ protocol 
other (2), -- none of the following 
hfdlp (3), 
v42 (4), 
lapm (5), 
munp (6), 
mnp10 (7) 
} 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 


"modem ARQ protocol; a set operation that specifies an unavailable mode shall 
effect no change" 
::= {hf modem 13 } 


modemCompressionProtocol OBJECT-TYPE 
SYNTAX INTEGER { 


none (1), -- no compression 
other (2), -- none of the following 
mnp (3), 
v42bis (4) 

} 

MAX-ACCESS read-write 

STATUS current 

DESCRIPTION 


"modem compression protocol; a set operation that specifies an unavailable mode 
shall effect no change" 
::= {hf modem 14 } 


-- the HF data link protocol group 


hfdIpProtocol Version OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"version of protocol in use by terminal" 
= {hfdlp 1} 


hfdlpControlMode OBJECT-TYPE 
SYNTAX INTEGER { 
varFrameARQ (1),-- variable-length control frames with ARQ 
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broadcast (2), -- fixed-length control frames with no ARQ 
circuitARQ (3), -- variable-length control frames with ARQ 
-- and "keep-alive" 
fixedFrameARQ (4) -- fixed-length control frames with ARQ 
} 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"control mode currently (or most recenlty) in use on link; set operation determines 
preference, but other terminal in a link can override varFrameARQ (1) or 
circuitARQ (3) to force fixedFrameARQ (4)" 
= {hfdlp 2} 


hfdlpNegotiationMode OBJECT-TYPE 
SYNTAX INTEGER { 


normal (1), -- negotiate changes only 
everySeries (2) -- negotiate between every data series 
} 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 


"negotiation mode currently (or most recently) in use on link; set operation 
determines preference, but other terminal in a link can override normal (1) to 
force everySeries (2)" 
::= {hfdlp3} 


hfdlpSelfAddress OBJECT-TYPE 
SYNTAX OCTET STRING (SIZE (2..18)) 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"address of this terminal" 
= {hfdlp 4} 


hfdlpOtherAddress OBJECT-TYPE 
SYNTAX OCTET STRING (SIZE (0..18)) 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"address of other terminal in link; zero-length string if no link; all 1s if broadcast" 
::= {hfdlp5} 


hfdlpLinkState OBJECT-TYPE 
SYNTAX INTEGER { 
idle (1), 
calling (2), 
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callAcknowledge (3), 
sending (4), -- transmit terminal in link-up state 
receiving (5), -- receive terminal in link-up state 
circuitIdle (6) -- link-up state, but no traffic in progress 
-- (ARQ Circuit Mode only) 
} 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 


"link establishment state of HFDLP terminal; only the following values are valid in 
a set operation: 
idle (1) forces terminal to drop link 
calling (2) initiates a (re)connection attempt 
sending (4) initiates Immediate mode message transfer" 
::= {hfdlp 6} 


hfdlpMaxRetries OBJECT-TYPE 
SYNTAX INTEGER (0..7) 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"maximum number of times transmit terminal will resend control frames; 0 means 
no retransmissions (set ignored by receive terminal)" 
= {hfdlp 7} 


hfdlpRetryCountdown OBJECT-TYPE 
SYNTAX INTEGER (0..7) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"remaining number of times terminal will send current control frame' 
::= {hfdlp 8} 


hfdlpLinkTimeout OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "100 ms" 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"link timeout value in use by a transmit terminal or receive terminal" 
= {hfdlp9} 


hfdlpFrameLength OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS read-write 
STATUS current 
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DESCRIPTION 
"data bytes per data frame in use by transmit terminal (set ignored by receive 
terminal)" 
::= {hfdlp 10} 


hfdIlpSeriesLength OBJECT-TYPE 

SYNTAX INTEGER 

MAX-ACCESS read-write 

STATUS current 

DESCRIPTION 

"frames per data series in use by transmit terminal (set ignored by receive 
terminal)" 
= {hfdlp 11} 


-- the AME group 


ameForwarding OBJECT-TYPE 
SYNTAX INTEGER { 
relay (1), -- entity forwards messages 
terminal (2) -- entity does not forward messages 
} 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"Enables or disables message relay in networking controller" 
::= {amel } 


ameAdaptiveRouting OBJECT-TYPE 

SYNTAX INTEGER { 

adaptive (1), -- entity automatically updates Routing 

-- Table from local data, HRMP, or HSSP 

static (2) -- entity doesn't automatically update Routing Table 
} 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 

"Enables or disables adaptive routing in networking controller. (Always reads as 

Static if no Routing Table.)" 

::= {ame 2} 


ameAlternateMedia OBJECT-TYPE 
SYNTAX INTEGER { 
hfOnly (1), -- entity routes messages only via HF links 
allMedia (2) -- entity routes messages via any available links 
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MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"Enables or disables multi media routing in networking controller. (Always reads 
as hfOnly if no Routing Table.)" 
:= {ame 3} 


ameRetryCount OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"Maximum number of delivery attempts before a message is discarded" 
::= {ame 4} 


ameRetryInterval OBJECT-TYPE 
SYNTAX INTEGER 
UNITS "seconds" 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"Initial retry interval for message delivery; subsequent intervals are larger" 
= {ame5} 


ameInReceives OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"Messages received by AME entity" 
::= {ame6} 


ameInForwMsgs OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"Messages forwarded by AME entity" 
::= {ame7} 
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ameInUnknPorts OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"Messages received by AME entity, but discarded due to unknown AME port 
numbers" 
:= {ame 8} 


ameInDelivers OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"Messages received by AME entity and delivered to higher-layer protocol" 
:= {ame 9} 


ameOutRequests OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"Messages from higher-layer protocol passed to AME entity for delivery." 
::= {ame 10} 


ameOutDiscards OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"Messages from higher-layer protocol discarded by AME entity after maximum 
retries" 
::= {ame 11 } 


-- the AME Routing Table 


ameRoutingTable OBJECT-TYPE 
SYNTAX SEQUENCE OF AmeRouteEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"The AME Routing Table" 

REFERENCE "see MIL-STD-187-721" 
= {ame 12} 
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ameRouteEntry OBJECT-TYPE 
SYNTAX AmeRouteEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"An entry in the AME Routing Table" 
INDEX { IMPLIED ameRouteDest ameRouteRank } 
::= { ameRoutingTable 1 } 


AmeRouteEntry ::= 
SEQUENCE { 
ameRouteDest 
AleAddress, 
ameRouteRank 
INTEGER, 
ameRoutelfIndex 
INTEGER, 
ameRouteNextHop 
AleAddress, 
ameRouteHops 
INTEGER, 
ameRouteStatus 
RowStatus 


} 


ameRouteDest OBJECT-TYPE 
SYNTAX AleAddress 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"Address of station to which message is to be routed" 
::= { ameRouteEntry 1 } 


ameRouteRank OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS read-create 
STATUS current 


DESCRIPTION 
"Order of this route among all listed routes to the destination (1 is highest ranking). 


Routes should be ranked in order of preference" 
DEFVAL {1} 
::= { ameRouteEntry 2 } 


ameRoutelfIndex OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS read-create 
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STATUS current 
DESCRIPTION 
"interface (link layer controller) to use for this route" 
DEFVAL {1} 


::= { ameRouteEntry 3 } 


ameRouteNextHop OBJECT-TYPE 
SYNTAX AleAddress 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
"address of relay (or destination if a direct route)" 
::= { ameRouteEntry 4 } 


ameRouteHops OBJECT-TYPE 
SYNTAX INTEGER 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
"number of hops (links) in this route to destination" 
DEFVAL {1} 
::= { ameRouteEntry 5 } 


ameRouteStatus OBJECT-TYPE 
SYNTAX RowStatus 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
"The status column used for creating, modifying, and deleting AME Routing Table 
entries" 
DEFVAL { active } 
::= { ameRouteEntry 6 } 


END 
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APPENDIX B 
ABSTRACT SYNTAX NOTATION (HNMP DEFINITIONS) 
HNMP DEFINITIONS ::= BEGIN 


IMPORTS 
ObjectName, ObjectSyntax, Integer32, MODULE-IDENTITY 
FROM SNMPv?2-SMI; -- RFC 1442 


hnmp MODULE-IDENTITY 
LAST-UPDATED "94080219142" 
ORGANIZATION "U.S. Army Information Systems Engineering Command" 
CONTACT INFO 
. Eric E. Johnson 


Postal: New Mexico State University 
Dept 3-O, (Electrical Computer Engineering) 
Las Cruces, NM 88003-0001 


USA 
Tel: +1 505 646 4739 
Fax: +1505 646 1435 
E-mail: ejohnson@nmsu.edu" 


DESCRIPTION "The HF Network Management Protocol for MIL/FED-STD automated 
HF radio networks" 
::= {hf 15 } -- normally encoded as { 2 43 15 } 


HfObjID ::= 
[PRIVATE 0] 
IMPLICIT OBJECT IDENTIFIER 
HfObjectName: : = 
CHOICE { 
long-form -- uses full path to the root 
ObjectName, 
short-form -- uses truncated path starting with HF MIB flag { 2 43 } 
encoded as 123 
HfObjID 
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} 
HfObjectSyntax: : = 
CHOICE { 
smi-object-value -- universal and application types from SMI 
ObjectSyntax, 
hfObjID-value -- truncated object ID starting with HF MIB flag { 2 43 } 
encoded as 123 
HfObjID 
} 
-- protocol data units 
PDUs::= 
CHOICE { 


get-request 
GetRequest-PDU, 


get-next-request 
GetNextRequest-PDU, 


get-bulk-request 
GetBulkRequest-PDU, 


get-rows-request 
GetRowsRequest-PDU, 


response 
Response-PDU, 


get-rows-response 
GetRowsResponse-PDU, 


set-request 
SetRequest-PDU, 


inform-request 
InformRequest-PDU, 


snmp V2-trap 
SNMPv2-Trap-PDU 
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} 


--PDUs 
GetRequest-PDU:: = 
[0] 
IMPLICIT PDU 


GetNextRequest-PDU:: = 
[1] 
IMPLICIT PDU 


Response-PDU:: = 
[2] 
IMPLICIT PDU 


SetRequest-PDU:: = 
[3] 
IMPLICIT PDU 


-- [4] is obsolete 


GetBulkRequest-PDU:: = 
[5] 
IMPLICIT BulkPDU 


InformRequest-PDU:: = 
[6] 
IMPLICIT PDU 


SNMPv2-Trap-PDU:: = 
[7] 
IMPLICIT PDU 


GetRowsRequest-PDU:: = 
[28] 
IMPLICIT BulkPDU 


GetRowsResponse-PDU:: = 


[29] 
IMPLICIT RowsPDU 
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max-bindings 
INTEGER: : =2147483647 


PDU::= 
SEQUENCE { 
request-id 
Integer32, 


error-status -- sometimes ignored 
INTEGER { 
noError(0), 
tooBig(1), 
noSuchName(2), -- for proxy compatibility 
badValue(3), -- for proxy compatibility 
readOnly(4), -- for proxy compatibility 
genErr(5), 
noAccess(6), 
wrongType(7), 
wrongLength(8), 
wrongEncoding(9), 
wrong Value(10), 
noCreation(11), 
inconsistentValue(12), 
resource Unavailable(13), 
commitFailed(14), 
undoFailed(15), 
authorizationError(16), 
notWritable(17), 
inconsistentName(18) 


err-index -- sometimes ignored 
INTEGER (0..max-bindings), 


variable-bindings -- values are sometimes ignored 
VarBindList 
} 


BulkPDU:: = -- MUST be identical in 
SEQUENCE { -- structure to PDU 
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request-id 
Integer32, 


non-repeaters 
INTEGER (0..max-bindings), 


max-repetitions 
INTEGER (0..max-bindings), 


variable-bindings -- values are ignored 
VarBindList 
} 
RowsPDU::= -- MUST be identical in 
SEQUENCE { -- structure to PDU 
request-id 
Integer32, 


non-repeaters 
INTEGER (0..max-bindings), 


max-repetions 
INTEGER (0..max-bindings), 


non-repeater-bindings 
VarBindList, 


row-bindings 
RowBindList 
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-- variable binding 


VarBind:: = 
SEQUENCE { 
name 
HfObjectName, 


CHOICE { 
value 
HfObjectSyntax, 

unSpecified -- inretrieval requests 

NULL, 
-- exceptions in responses 

noSuchObject[0] 

IMPLICIT NULL, 


noSuchInstance[1] 
IMPLICIT NULL, 


endOfMibView[2] 
IMPLICIT NULL 
} 


} 
-- variable-binding list 
VarBindList: : = 


SEQUENCE (SIZE (0..max-bindings)) OF 
VarBind 
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-- row-binding 


RowBind:: = 
SEQUENCE { 
name -- object name of first object only 
HfObjectName, 


SEQUENCE OF -- followed by values of all objects request in row 
CHOICE { -- containing first object 
value 
HfObjectSyntax, 
-- exceptions in responses 
noSuchObject[0] 
IMPLICIT NULL, 


noSuchInstance[1] 
IMPLICIT NULL, 


endOfMibView[2] 
IMPLICIT NULL, 


wrongRow[3] 
IMPLICIT NULL 


-- row-binding list 
RowBindList:: = 
SEQUENCE OF 
RowBind 


END 
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